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Preface 



Rod JOHNSON 

Founder, Spring Framework, CEO, Interface21 

French readers have had to wait longer than most for a book on Spring in their native 
language. However, the wait has not been in vain, and they are fortunate in this, the first 
book on Spring in French. 

It is almost five years since I wrote the first code towards what would later become the Spring 
Framework. The open source project formally began in February 2003, soon making the 
product far more than any individual could achieve. Since that time, Spring has become widely 
used worldwide, powering applications as diverse as retail banking portals; airline reservation 
systems; the French online tax submission system; payment engines handling inter-bank trans- 
fers, salaries and utility bills; search engines; government agency portals including that of the 
European Patent Office; critical scientific research systems; logistics solutions; and football 
web sites. In that time, Spring also spawned a rich literature, in a variety of languages. 
This book does an excellent job, not merely of describing what Spring does, and how, but 
the central issue of why. Excellent examples illustrate the motivation for important Spring 
concepts and capabilities, making it not merely a book about a particular product, but a 
valuable book about writing effective server-side Java applications. 

While this book is ideal as an introduction to Spring and modern concepts such as Depen- 
dency Injection and Aspect Oriented Programming, it always respects the reader. The 
authors never write down to their readership. While their experience stands out, and they 
offer clear guidance as to best practice, the reader feels involved in their discussion of 
architectural choices and trade-offs. 

The content is not only up to date, but broad in scope and highly readable. Enterprise Java is 
a dynamic area, and open source projects are particularly rapidly moving targets. Spring has 
progressed especially rapidly in the last six months, with work leading up to the final release 
of Spring 2.0. The authors of this book have done a remarkable job of writing about Spring 
2.0 features as soon as they have stabilized. The coverage of AJAX is also welcome. 
The writing style is clear and to the point, making the book a pleasure to read. 
Finally, the authors' commitment to providing a realistic sample application (rather than the 
simplistic effort that mars many books), is shown by the fact that Tudu Lists has become a 
viable open source project in its own right. 

I highly recommend this book to all those new to the Spring Framework or wishing to 
deepen their understanding of it, as well as those who wish to understand the current state 
of enterprise Java development. 
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Rod JOHNSON, 

fondateur du framework Spring et president d'Interface21 

Si les lecteurs francophones ont du patienter plus que d' autres pour avoir acces a un livre 
sur Spring ecrit dans leur langue, leur attente n'aura pas ete vaine, puisque ce premier 
ouvrage en francais dedie a Spring est une grande reussite. 

Voici bientot cinq ans que j'ai ecrit les premieres lignes du code de ce qui allait devenir le 
framework Spring. Le projet Open Source lui-meme n'a reellement debute qu'en 
fevrier 2003, pour aboutir rapidement a un produit outrepassant de beaucoup ce qu'une 
seule personne aurait pu realiser. Aujourd'hui, Spring est largement utilise a travers le 
monde, dans des applications aussi diverses que des portails bancaires publics, des syste- 
mes de reservation de billets d' avion, le systeme francais de declaration de revenus en 
ligne, des moteurs de paiements assurant les transferts interbancaires ou la gestion de la 
paie et des factures, des moteurs de recherche, des portails de services gouvernementaux, 
dont celui de 1' Office europeen des brevets, des systemes critiques de recherche scientifi- 
que, des solutions de logistique ou des sites... dedies au football. Durant toute cette 
periode, Spring a fait Fobjet d'une abondante litterature, dans un grand nombre de langues. 

Au-dela de la description de ce que fait Spring et de la facon dont il le fait, toute l'origina- 
lite de ce livre reside dans sa facon de repondre a la question centrale du pourquoi. Les tres 
bons exemples qui illustrent les motivations ay ant conduit a 1' elaboration des concepts et 
des fonctionnalites fondamentales de Spring en font, bien plus qu'un simple manuel de 
prise en main, un ouvrage de reference pour quiconque souhaite realiser efficacement des 
applications Java cote serveur. 

Ideal pour une introduction a Spring et a des concepts aussi modernes que l'injection de 
dependances ou la programmation orientee aspect, ce livre respecte en outre toujours le 
lecteur, les auteurs s'etant fait un point d'honneur de ne jamais le prendre de haut. Tout en 
profitant de leur vaste experience et de leur clair expose des meilleures pratiques, le lecteur 
se sent continuellement implique dans leur presentation critique des choix d' architecture et 
des compromis qui en decoulent. 

Le contenu de l'ouvrage est parfaitement a jour et couvre une large gamme de sujets. J2EE 
est un domaine tres actif, dans lequel les projets Open Source evoluent de maniere extreme - 
ment rapide. Spring lui-meme a fortement progresse au cours des six derniers mois, pour 
atteindre sa version finalisee Spring 2.0. Les auteurs de ce livre ont accompli une veritable 
prouesse pour traiter des fonctionnalites de cette version de Spring 2.0 des qu'elles ont pu 
etre stabilisees. La couverture de la technologie AJAX est en outre particuherement bienvenue. 

Pour finir, les auteurs ont fait l'effort d'adjoindre au livre une application exemple realiste 
plutot qu'une etude de cas simpliste, comme on en trouve dans trop d'ouvrages. Cette 
application, Tudu Lists, est meme devenue un projet Open Source a part entiere, avec deja 
de nombreux utilisateurs. 

Ajoutons que le style d'ecriture est clair et pragmatique, rendant le parcours du lecteur tres 
agreable. 

Pour toutes ces raisons, je ne saurais trop recommander la lecture de cet ouvrage a ceux qui 
debutent dans l'utilisation du framework Spring ou qui souhaitent en approfondir la 
maitrise comme a ceux qui ont a coeur de mieux comprendre Fetat de Fart du developpement 
Java d'entreprise. 
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Avant-propos 



Spring est un framework Open Source rendant l'utilisation de J2EE a la fois plus simple 
et plus productive. Tout au long de cet ouvrage, nous nous efforcons de degager les 
bonnes pratiques de developpement d' applications Java/J2EE, dont une large part ne sont 
pas specifiques de Spring, mais dont la mise en oeuvre est grandement simplified et 
rendue plus consistante grace a son utilisation. 

Spring s'appuie sur des concepts modernes, tels que l'inversion de controle ou la 
programmation orientee aspect, afin d'ameliorer 1' architecture des applications Java/ 
J2EE en les rendant tout a la fois plus souples, plus agiles et plus facilement testables. 

S' integrant avec les grands frameworks Open Source tels que Struts ou Hibernate, ainsi 
qu'avec les standards J2EE, Spring propose un modele d' application coherent, complet 
et simple d'emploi. 

Recommande par de nombreux architectes et developpeurs experimentes, Spring 
commence a se diffuser au sein des SSII et des entreprises francaises. Une bonne 
connaissance de ce produit est done essentielle dans le monde tres concurrentiel de 
l'informatique d'entreprise d'aujourd'hui. 

Objectifs de cet ouvrage 

Cet ouvrage se veut un guide pratique pour le developpement d' applications Java/J2EE 
fondees sur Spring. 

Nous avons voulu le rendre accessible au plus grand nombre arm de permettre aux 
developpeurs Java/J2EE d'etre plus productifs et de mieux reussir leurs projets grace a 
l'utilisation de Spring. 

C'est la raison pour laquelle nous n'entrons pas dans la description d'API complexes. 
II s'agit avant tout d'un ouvrage didactique, destine a rendre le lecteur directement 
operationnel. 

Cette volonte d' accessibility ne signifie pas pour autant que 1' ouvrage soit d'une lecture 
simple et peu technique. Lorsque c'est necessaire, nous abordons aussi des themes 
complexes, comme les transactions avec JTA ou 1' integration avec JCA. 
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Convaincus que Ton apprend mieux par la pratique, nous adjoignons a l'ouvrage une 
etude de cas pratique, 1' application Tudu Lists, developpee pas a pas tout au long des 
chapitres. Le lecteur a de la sorte sous les yeux, au fur et a mesure de sa progression dans 
l'ouvrage, des exemples de mise en oeuvre concrete, dans une application reelle, des 
sujets traites. 

Organisation de l'ouvrage 

L'ouvrage commence par decrire des concepts et des problemes courants des applica- 
tions Java/J2EE, avant d'aborder en douceur l'utilisation du conteneur Spring. Des sujets 
classiques sont egalement traites, tels que les frameworks MVC ou le mappage objet/ 
relationnel, en montrant de quelle maniere Spring permet d'etre plus efficace dans la 
mise en ceuvre de ces techniques. 

L'ouvrage comporte cinq grandes parties : 

• La premiere partie introduit les principaux concepts de Spring. L'injection de depen- 
dances et la programmation orientee aspect y sont decrits et detailles, d'abord de maniere 
globale puis de maniere specifique a Spring. 

• La partie II concerne la couche de presentation d'une application Web. Nous y presen- 
tons le tres classique Struts, ainsi que deux frameworks specifiques de Spring : Spring 
MVC et Spring Web Flow. Nous passons egalement en revue les deux concepts tres 
populaires que sont les portlets et les technologies AJAX. 

• La partie III est dediee a la couche de persistance des donnees, essentiellement le 
mappage objet/relationnel et la gestion des transactions. 

• Une application ayant souvent besoin d'interagir avec d'autres systemes, la partie IV 
s'interesse aux technologies d'integration. Cette integration peut etre realisee en Java, 
avec les technologies JCA ou JMS, mais egalement en XML, en particulier via des 
services Web. Cette partie se conclut par un chapitre dedie a la securite des applications. 

• La partie V presente deux technologies connexes, qui permettent d' ameliorer la qualite 
d'une application dans son ensemble : la supervision, avec JMX, et les tests unitaires, 
avec JUnit. 

A propos de I'applicationTudu Lists 

L' application Tudu Lists, qui nous sert d'etude de cas tout au long de l'ouvrage, est un 
exemple concret d'utilisation des technologies Spring. II s'agit d'un projet Open Source 
reel, qui a ete realise specifiquement pour cet ouvrage, et qui permet d'illustrer par 
l'exemple les techniques decrites dans chacun des chapitres. 

Loin de n'etre qu'un simple exemple, cette application est utilisee en production depuis 
quelques mois dans plusieurs entreprises. Le principal serveur Tudu Lists possede ainsi 
plus de 5 000 utilisateurs. 



Avant-propos 

Chapitre 



Cette application etant Open Source, le lecteur est invite a participer a son developpement. 
Elle est disponible sur le site de SourceForge, a l'adresse http://tudu.sourceforge.net. 

A qui s'adresse I'ouvrage? 

Cet ouvrage s'adresse a tout developpeur J2EE souhaitant ameliorer sa productivite et 
ses methodes de developpement et s'interessant a 1' architecture des applications. 

II n'est nul besoin d'etre expert dans les differentes technologies presentees. Chaque 
chapitre presente clairement chacune d'elles puis montre comment elle est implemented 
dans Spring avant d'en donner des exemples de mise en oeuvre dans l'application Tudu 
Lists. 

Pour toute question concernant cet ouvrage, vous pouvez contacter les auteurs sur la page 
Web dediee a I'ouvrage du site d'Eyrolles, a l'adresse www.editions-eyrolles.com. 
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Les developpements Java/J2EE, notamment ceux qui utilisent les EJB, sont reputes 
complexes, tant en terme de developpement que de tests et de maintenance. La producti- 
vite des developpeurs Java/J2EE ne disposant que des standards constituant la plate- 
forme est faible, comparee a celle obtenue avec d'autres technologies, comme les langages 
de type RAD (Rapid Application Development). Sur les projets Java/J2EE de taille 
consequente, une couche d' abstraction est generalement developpee afin de simplifier le 
travail des developpeurs et leur permettre de se concentrer davantage sur la reelle valeur 
ajoutee d'une application, a savoir le metier. 

C'est a partir de ce constat que les concepteurs de Spring, experts J2EE de renommee 
mondiale, ont imagine une solution permettant de simplifier et structurer les develop- 
pements J2EE de maniere a respecter les meilleures pratiques d' architecture logicielle. 

Spring est a ce titre un veritable cadre de travail. Non content de structurer les developpe- 
ments specifiques d'un projet, il propose une integration des frameworks tiers les plus 
repandus. Grace aux communautes Open Source tres actives du monde Java, un grand 
nombre de frameworks specialises sur differentes problematiques sont apparus, notam- 
ment Struts pour la couche presentation des applications et Hibernate pour la persistance 
des donnees. Ainsi, il n'est pas rare d'utiliser au sein d'un meme projet plusieurs 
frameworks specialises. 

Spring simplifie 1' utilisation de ces frameworks en les inserant dans son cadre de travail. 
La vocation de Spring est d'offrir, non pas toutes les fonctionnalites dont un developpeur 
pourrait rever, mais une architecture applicative generique capable de s' adapter a ses 
choix technologiques en terme de frameworks specialises. 
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Cet ouvrage ambitionne de proposer une vision globale de Spring, afin d'en presenter 
toute la richesse et d'en faciliter la mise en oeuvre dans des projets. Nous commencons 
dans ce chapitre par aborder les problematiques rencontrees dans les projets Java/J2EE 
classiques, a savoir la separation des preoccupations techniques et fonctionnelles, la 
productivity des developpements, l'independance du code vis-a-vis de la plate-forme 
d'execution et les tests. 

Spring apporte des reponses a ces problematiques en se reposant sur la notion de conte- 
neur leger et sur la POA (programmation orientee aspect) et en introduisant 
les meilleures pratiques en matiere d' architecture applicative et de developpement 
d' applications. 

En fin de chapitre, nous introduisons 1' etude de cas Tudu Lists, tiree d'un projet Open 
Source, qui nous servira de fil conducteur tout au long de 1' ouvrage. Au travers de sa 
mise en oeuvre concrete, nous illustrerons tous les principes fondamentaux de Spring 
ainsi que 1' integration des differentes technologies manipulees par les projets Java J2EE 
(persistance des donnees, gestion des transactions, etc.). 

Problematiques des developpements Java/J2EE 

J2EE constitue une infrastructure complexe, qui demande un niveau technique non negli- 
geable pour etre bien maitrisee. Par rapport au developpement d' applications metier, 
cette infrastructure souleve un certain nombre de difficultes, auxquelles tout developpeur 
Java/J2EE est confronte un jour ou 1' autre, notamment les quatre problemes majeurs 
suivants : 

• J2EE n'encourage pas intrinsequement une bonne separation des preoccupations, 
c'est-a-dire l'isolation des differentes problematiques qu'une application doit gerer 
(typiquement, les problematiques techniques, d'une part, et les problematiques metier, 
d' autre part). 

• J2EE est une plate -forme complexe a maitriser, qui pose des problemes de producti- 
vite importants, la part des developpements consacres aux problematiques techniques 
etant disproportionnee par rapport a celle vouee aux problematiques fonctionnelles, 
qui est pourtant la veritable valeur ajoutee d'une application. 

• J2EE impose une plate-forme d'execution lourde, qui pose des problemes d'interope- 
rabilite entre differentes implementations. Elle peut aussi nuire a la reutilisation des 
services composant une application, si ceux-ci doivent fonctionner sur du materiel ne 
pouvant supporter un serveur d' applications dans le cadre d'une utilisation nomade 
(assistants personnels, telephones, etc.). 

• Les developpements utilisant J2EE s'averent souvent difficiles a tester du fait de leur 
forte dependance vis-a-vis de cette plate -forme et de la lourdeur de celle-ci. 

Nous detaillons dans cette section ces differentes problematiques, qui nous serviront de 
reference dans le reste de l'ouvrage pour illustrer tout l'interet d'utiliser un framework tel 
que Spring dans nos developpements J2EE. 
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La separation des preoccupations 

Le concept de separation des preoccupations consiste a isoler au sein des applications les 
differentes problematiques qu'elles ont a traiter. Deux categories de preoccupations 
parmi les plus evidentes sont les preoccupations d'ordre technique, a l'image des meca- 
nismes de persistance des donnees, et les preoccupations d'ordre metier, comme la 
gestion des donnees de l'entreprise. 

L'idee sous-jacente a la separation des preoccupations est de garantir une meilleure 
evolutivite des applications grace a une bonne isolation des differentes problematiques. 
Chaque preoccupation est traitee de la maniere la plus independante possible des autres 
afin d'en perenniser au maximum le code, tout en limitant les effets de bord lies a 
revolution d'une preoccupation. 

En specifiant J2EE (Java 2 Enterprise Edition), Sun Microsystems visait a transformer le 
langage Java en un veritable langage d'entreprise, permettant une separation nette entre 
les developpeurs « techniques » et les developpeurs « metier ». L'objectif avoue de cette 
separation etait de permettre a des non-informaticiens de prendre en charge directement 
le developpement des composants implementant la logique metier, en 1' occurrence les 
EJB (Enterprise JavaBeans), en connaissant le strict minimum de programmation neces- 
saire. Force est de constater que les EJB n'ont pas tenu leurs promesses. 

L'une des raisons de cet echec est que la separation des preoccupations au sein d'une 
architecture J2EE se fondant uniquement sur les EJB n'est pas suffisante pour isoler 
completement les developpements metier des problematiques techniques. La conception 
meme des composants metier est directement influencee par 1' architecture technique 
sous-jacente. Combien de projets J2EE ont echoue pour avoir utilise des EJB d'une 
maniere ingerable par le serveur d' applications, par exemple en definissant des EJB 
Session ayant une granularite trop fine ? 

Par ailleurs, la separation des preoccupations est limitee a des preoccupations specifi- 
ques, et J2EE ne propose pas de mecanisme generique permettant d'elargir ce perimetre. 
En l'occurrence, la separation des preoccupations porte essentiellement sur les EJB, alors 
qu'une application ne se resume pas, loin s'en faut, a ces derniers. Les preoccupations 
techniques liees a la persistance des donnees, aux transactions ou a la securite peuvent 
concerner bien d' autres composants de 1' application. 

La productivity des developpements 

Si les normes J2EE definissent une infrastructure technique de base pour developper des 
applications, celle-ci s'avere insuffisante en terme de productivite par rapport a d'autres 
technologies. Ces normes occultent le probleme de la productivite, laissant place a des 
solutions complementaires masquant la complexite de la technologie mais faisant perdre 
en meme temps les gains attendus de la standardisation. 

La mise en place de ces solutions, regulierement developpees specifiquement pour un 
projet, a impacte fortement les budgets d'investissement, souvent aux depens des deve- 
loppements strictement metier. Si 1' utilisation de technologies standards est un gage de 
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perennite, la seule standardisation ne suffit pas a repondre aux besoins des clients, dont 
l'objectif est toujours d'avoir plus pour moins cher. 

Pour combler les lacunes de la plate-forme J2EE, la lenteur de son instance de standardi- 
sation, le JCP (Java Community Process), et eviter d'avoir a developper et maintenir des 
solutions maison, la communaute Java, a du s'appuyer sur des offres complementaires, 
notamment Open Source. 

Pour gagner en productivite, les projets Java/J2EE actuels abandonnent les solutions 
maison au profit de frameworks tiers implementant les meilleures pratiques disponibles. 
L'exemple qui vient immediatement a l'esprit est celui de Struts. Ce framework, ou cadre 
de travail, structure les developpements Web selon un modele de conception eprouve 
depuis le langage SmallTalk, le modele MVC (Model View Controller) et fournit une 
boite a outils rudimentaire pour structurer et accelerer les developpements. 

Malheureusement, les frameworks sont des outils specialises dans une problematique 
donnee, a l'image de Struts pour le Web ou Log4J pour les traces applicatives. Pour 
parvenir a un niveau de productivite satisfaisante, il est done necessaire de recourir a 
plusieurs frameworks. Cela pose d'evidents problemes d'integration de ces frameworks 
au sein des applications, problemes auxquels J2EE n'apporte aucune reponse. 

L'independance vis-a-vis de la plate-forme d'execution 

Pour respecter un de ses principes fondateurs, le fameux « Write Once, Run Anywhere » 
(ecrire une fois, executer partout), Java repose sur une machine virtuelle permettant de 
s'abstraire des plates-formes materielles sous-jacentes. 

Avec J2EE, ce principe fondateur se heurte a deux ecueils : la difficulte de standardisation 
d'une technologie complexe et le choix d'une architecture exclusivement orientee serveur. 

La standardisation est un processus long et difficile. Si plusieurs acteurs sont impliques, 
il est necessaire de trouver un consensus sur le contenu du standard. Par ailleurs, ce stan- 
dard doit laisser le moins de place possible a l'ambiguite et a l'imprecision, autant de 
niches engendrant des implementations incompatibles. 

Au finale, les premieres implementations du standard J2EE se sont averees assez liees au 
serveur d' applications sous-jacent. La situation s'est nettement amelioree depuis, avec la 
mise en place d' implementations de reference et d'un processus de certification tres 
rigoureux. Cependant, certains aspects, comme la securite, ne sont que partiellement 
couverts par la norme J2EE, ouvrant la porte aux solutions proprietaries. 

Le deuxieme ecueil vient de 1' orientation exclusivement serveur de J2EE, un choix 
« politique » de la part de Sun Microsystems, selon qui « the Network is the Computer » 
(le reseau est l'ordinateur). Malheureusement, cette orientation reseau est prejudiciable a 
certains types d'applications, notamment celles qui doivent fonctionner sans reseau et 
qui necessitent generalement des services de persistance des donnees et de gestion des 
transactions. Le code metier reposant sur les EJB necessite un serveur d'applications 
pour s'executer. Or l'installation d'un serveur d'applications J2EE directement sur un 
poste de travail nomade ou un assistant personnel est difficilement justifiable. 
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Finalement, J2EE repond a des problematiques fortes mais pose des problemes d'intero- 
perabilite au niveau des EJB, qui nuisent a la reutilisation des composants construits sur 
cette architecture. Par ailleurs, 1' orientation reseau de J2EE gene son utilisation dans 
certains domaines comme le nomadisme. 

Les tests 

La problematique des tests est fondamentale dans tout developpement d' application. La 
technologie J2EE s'avere complexe a tester, car elle necessite un serveur d' applications 
pour s'executer. De cette necessite resultent une execution des tests lourde et une diffi- 
culty d'automatisation. 

Dans les faits, il s'agit davantage de tests d'integration que de tests reellement unitaires. 
Des solutions telles que Cactus, de la communaute Apache Jakarta, restent lourdes a 
mettre en oeuvre par rapport a l'outillage disponible pour les classes Java classiques 
(frameworks derives de JUnit, Mock Objects, etc.). 

La difficulte de tester une application Java/J2EE selon une granularite plus fine que les 
tests d'integration nuit fortement a la qualite des applications construites sur cette plate- 
forme. D'ou des problemes de productivite et de maintenance evidents. 

En resume 

Nous avons vu que J2EE posait des problemes penalisants pour le developpement des 
applications. J2EE n' encourage pas intrinsequement de bonnes pratiques de conception, 
comme la separation des preoccupations. La lourdeur de cette plate-forme rend de 
surcroit 1' application dependante du serveur d' applications sur lequel elle fonctionne, et 
les tests de ses composants s'averent difficiles a mettre en oeuvre. 

Face a ce constat, les concepteurs de Spring ont developpe un framework permettant 
d'adresser ces problematiques de maniere efficace. 

Reponses de Spring 

Pour resoudre les problemes que nous venons d'evoquer, des solutions ont emerge. En 
rupture avec les conteneurs J2EE, disqualifies par de nombreux experts pour leur lour- 
deur, sont apparus des conteneurs dits legers. Le coeur de Spring entre dans cette catego- 
rie de solutions. 

Ce coeur a ete etendu de maniere a supporter la POA (programmation orientee aspect), ou 
AOP (Aspect Oriented Programming), un nouveau paradigme de programmation 
permettant d'aller au-dela de l'approche objet en terme de modularisation des compo- 
sants. Au-dessus de ce socle, des modules optionnels sont proposes afin de faciliter 
l'integration de frameworks specialises. 

Les sections qui suivent detaillent la fagon dont Spring resout les problemes souleves par 
l'utilisation de J2EE. 
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La notion de conteneur leger 

La notion de conteneur EJB est une technologie lourde a mettre en oeuvre, inadaptee pour 
les objets a faible granularite, intrusive dans le code et en partie dependante du serveur 
d' applications, ne serait-ce qu'en terme de configuration. 

En fournissant une infrastructure de gestion de l'ensemble des composants de 1' applica- 
tion, les conteneurs legers adoptent une approche foncierement differente. Cela s'effec- 
tue au travers de mecanismes de configuration, comme les fichiers XML permettant 
d'initialiser les composants, de gestion du cycle de vie des composants et de gestion des 
dependances entre les composants. Les conteneurs legers sont independants de la techno- 
logie J2EE et peuvent fonctionner sur tout type de serveur d' applications, voire sans eux 
en utilisant une simple machine virtuelle Java. 

Les conteneurs legers rendent les applications qui les utilisent a la fois plus flexibles et 
mieux testables, car le couplage entre les composants est gere par le conteneur, et non 
plus directement a l'interieur du code. Par ailleurs, les conteneurs legers encouragent 
l'utilisation intensive d'interfaces afin de rendre l'application independante de leurs 
implementations. Cela se revele notamment utile pour les tests, dans lesquels il est 
souvent necessaire de remplacer une implementation reelle par un simulacre d'objet, ou 
Mock Object. Le debogage est facilite, puisqu'il n'est pas necessaire d'executer le code 
au sein d'un serveur d' applications et que le conteneur leger est peu intrusif dans le code de 
l'application. 

Pour nous faire une idee plus precise de la nature d'un conteneur leger, nous pouvons 
etablir un parallele avec les frameworks gerant les interfaces graphiques, comme Swing 
ou SWT (Standard Widget Toolkit). Avec ces outils, nous definissons les composants 
graphiques a utiliser et nous nous connectons aux evenements qu'ils sont susceptibles de 
generer, un clic sur un bouton, par exemple. Ces frameworks prennent en charge le cycle 
de vie des composants graphiques de maniere completement transparente pour l'appli- 
cation concernee. Un conteneur leger peut offrir des services similaires, mais avec des 
objets de toute nature. 

Nous detaillons au chapitre 2 le fonctionnement des conteneurs legers et abordons les 
modeles de conception, ou design patterns, sur lesquels ils se fondent. 

A la difference d'autres conteneurs legers du marche, notamment HiveMind ou PicoContai- 
ner, Spring propose bien d'autres fonctionnalites, comme le support de la POA ou 1' inte- 
gration de frameworks tiers. 

Le support de la POA 

Outre son conteneur leger, Spring supporte la POA (programmation orientee aspect), ou 
AOP (Aspect-Oriented Programming). Ce support est utilise en interne par Spring pour 
offrir des services similaires a ceux des conteneurs EJB, mais sans leur lourdeur, car ils 
sont applicables a de simples JavaBeans, ou POJO (Plain Old Java Objects). Ce support 
peut aussi etre utilise par les utilisateurs de Spring pour leurs propres besoins. 
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La POA est un nouveau paradigme de programmation, dont les fondations ont ete defi- 
nies au centre de recherche Xerox, a Palo Alto, au milieu des annees 1990. Par para- 
digme, nous entendons un ensemble de principes qui structurent la maniere de modeliser 
les applications et, en consequence, la facon de les developper. 

Elle a emerge a la suite de differents travaux de recherche, dont l'objectif etait d'ameliorer 
la modularite des logiciels afin de faciliter la reutilisation et la maintenance. 

La POA ne remet pas en cause les autres paradigmes de programmation, comme l'appro- 
che procedurale ou l'approche objet, mais les etend en offrant des mecanismes comple- 
mentaires, afin de mieux separer les differentes preoccupations d'une application, et une 
nouvelle dimension de modularisation, V aspect. 

Dans son principe, la POA consiste a modulariser les elements logiciels mal pris en 
compte par les paradigmes classiques de programmation. En l'occurrence, la POA se 
concentre sur les elements transversaux, c'est-a-dire ceux qui se trouvent dupliques ou 
utilises dans un grand nombre d'entites, comme les classes ou les methodes, sans pouvoir 
etre centralises au sein d'une entite unique avec les concepts classiques. Ainsi, grace a la 
notion d' aspects, qui capturent en leur sein les preoccupations transversales, la separation 
des preoccupations est nettement amelioree. 

Avec les EJB, notamment les EJB Entity CMP, un premier niveau de separation des 
preoccupations a ete atteint. Un grand nombre d' aspects techniques sont en effet pris en 
charge sous forme de descripteurs de deploiement (mapping objet-relationnel, securite et 
transactions, etc.) et n' apparaissent plus dans le code metier. La maintenance en est 
d'autant facilitee. 

La POA va au-dela en offrant des mecanismes generiques pour modulariser un grand 
nombre d'elements transversaux des logiciels. Les limites des outils de POA pour captu- 
rer les preoccupations transversales tiennent essentiellement a leur capacite a exprimer le 
perimetre de celles-ci et a la facon dont elles sont liees au reste de 1' application. 

Spring n'implemente pas toutes les notions de la POA, mais l'essentiel est present et faci- 
lement utilisable. Pour des besoins plus pousses, l'utilisation d'un framework tiers est 
permise. Spring s'integre notamment avec AspecU, l'outil precurseur de la POA et qui 
demeure le plus populaire a ce jour, mais cette integration se limite aux aspects de type 
singleton. 

Diverses fonctionnalites avancees de Spring reposent sur la POA, notamment les suivan- 
tes : 

• gestion des transactions ; 

• gestion de cache ; 

• notification d'evenements. 

Grace a la POA, Spring offre des services proches de ceux fournis par J2EE, mais sans se 
limiter aux seuls EJB. Ces services peuvent de la sorte etre utilises avec tout objet Java. 
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L Integration de frameworks tiers 

L' integration de frameworks tiers dans Spring repose sur la notion de conteneur leger et, 
dans une moindre mesure, sur la POA. 

Cette integration peut s'effectuer aux trois niveaux suivants : 

• integration des composants du framework tiers au sein du conteneur leger et configu- 
ration de ses ressources ; 

• mise a disposition d'un template, ou modele, d' utilisation et de classes de support ; 

• abstraction de l'API. 

En fonction du framework, 1' integration de celui-ci est plus ou moins poussee, le mini- 
mum etant 1' integration des composants du framework dans le conteneur leger. Cette 
integration consiste a configurer et realiser une injection de dependances sur ces compo- 
sants. Elle est generalement peu intrusive du point de vue de 1' application qui utilise le 
framework tiers, c'est-a-dire qu'aucune dependance forte n'est creee a l'egard de Spring. 

Le deuxieme degre d'integration consiste en la mise a disposition d'un template d'utili- 
sation et de classes de support. II s'agit ici de faciliter l'utilisation du framework tiers en 
simplifiant les appels a son API et en implementant les meilleures pratiques. 

Pour cela, differentes techniques sont utilisees. L'une d'elles consiste en la transforma- 
tion systematique des exceptions verifiees (checked exceptions), c'est-a-dire les excep- 
tions devant etre obligatoirement prises en charge par une clause catch dans le code et les 
clauses throws specifiees dans les signatures des methodes, en exceptions d'execution 
(runtime exceptions), plus simples a gerer de maniere centralisee. Dans ce cas, l'utilisation 
d'un template lie le code de 1' application explicitement a Spring. 

Le troisieme degre d'integration consiste a s'abstraire de l'API du framework tiers. 
L'objectif est ici de normaliser l'utilisation d'un ensemble de frameworks repondant a 
des besoins similaires. C'est typiquement le cas du support des DAO (Data Access 
Objects), ou objets d'acces aux donnees, par Spring, qui normalise l'utilisation de ce 
concept quel que soit le framework de persistance utilise (Hibernate, OJB, etc.). 

L abstraction d'API ne permet toutefois pas de s'abstraire completement des 
frameworks sous-jacents, car cela reviendrait a choisir le plus petit denominateur 
commun et a perdre ainsi la richesse des fonctionnalites avancees de ces frameworks. 
Le parti pris de Spring consiste a abstraire les points communs sans pour autant 
masquer le framework tiers. C'est un choix pragmatique, qui diminue les couts de 
remplacement d'un framework par un autre, sans occulter les gains de productivite 
induits par leur utilisation poussee. 

Grace a ces differents degres d'integration, Spring constitue le ciment permettant de lier 
les differents frameworks mis en oeuvre avec le code applicatif dans un ensemble cohe- 
rent et implementant les meilleures pratiques. La productivite et la maintenabilite des 
applications en sont d' autant ameliorees. 
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Architecture globale de Spring 

A partir de ces trois principes que sont le conteneur leger, la POA et 1' integration de 
frameworks tiers, Spring propose un cadre de developpement permettant de construire 
des applications de maniere modulaire. 

La figure 1.1 illustre les differentes briques constituant 1' architecture de Spring, ainsi que 
les principaux frameworks tiers (representes en pointilles) dont elles assurent 1' integration. 
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Figure 1.1 

Architecture de Spring 



Comme nous pouvons le voir, Spring repose sur un socle technique constitue des modu- 
les : 

• Spring Core, le conteneur leger ; 

• Spring AOP, le framework de POA. 

Sur ce socle sont construits des modules de plus haut niveau destines a integrer des 
frameworks tiers ou a fournir des fonctions de support. Ces modules sont les suivants : 

• Modules d' integration de la persistance des donnees (Spring DAO pour 1' abstraction 
de la notion d'objets d'acces aux donnees, Spring ORM pour l'integration de 
frameworks de persistance, Spring JDBC pour simplifier 1' utilisation de JDBC). Les 
principaux frameworks de persistance du marche sont supportes. 

• Module de gestion de contexte applicatif (Spring Context), qui assure le dialogue entre 
Spring et l'application, independamment de la plate-forme technique sur laquelle 
fonctionne cette derniere (au sein d'un serveur d'applications, d'une simple JVM, 
etc.). 
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• Module d' integration de frameworks Web (Spring Web), qui supporte les principaux 
frameworks Open Source du marche. Spring propose en outre son propre framework 
Web, concu sur le modele MVC, sous le nom de Spring MVC. 

• Module de distribution d'objets (Spring Remoting), qui permet de transformer de 
simples classes Java en objets distribues RMI, Web Services ou autres. 

• Module d'integration d'ordonnanceur de taches, qui supporte actuellement Quartz 
d'OpenSymphony et le Timer fourni par le JDK. 

• Modules de support des differentes technologies J2EE (JMX, JMS, JCA et EJB). 

Comme nous pouvons le constater, l'offre de Spring couvre l'essentiel des frameworks 
utilises par les applications J2EE actuelles, ce qui en fait une solution pertinente pour 
tout developpement. De plus, Spring n'est pas une solution fermee, comme nous le 
verrons a la section suivante. 

Spring propose enfin les sous-projets suivants, qui viennent completer ses fonctionnalites : 

• Acegi Security System for Spring, qui permet de gerer l'authentification et les autori- 
sations au sein d'une application developpee avec Spring. 

• Spring Web Flow, qui permet de gerer la navigation au sein de pages Web. 

• Spring Rich Client, qui permet d'accelerer le developpement d' applications Swing en 
se fondant sur Spring. 

• Spring BeanDoc, qui permet de documenter 1' utilisation des artefacts de Spring 
utilises dans les applications. 

• Spring IDE, un plug-in Eclipse qui permet d'accelerer les developpements en gerant 
les composants de Spring au sein de cet environnement de developpement. 

Le projet Spring Modules (voir https://springmodules.dev.java.net/) a pour objectif d'integrer 
d'autres frameworks et outils sans modifier le coeur de Spring. A ce jour, Spring Modules 
integre des frameworks tels que OSWorkflow, Commons Validator, Drools, etc. 

Spring dispose aussi d'une implementation pour le monde Microsoft, avec Spring. Net 
(http://www.springframework.net/). 

En resume 

Spring est une solution elegante qui repond a un ensemble de problematiques essentielles 
des developpements Java/J2EE, notamment la flexibilite du code, l'integration de 
frameworks tiers et 1' implementation des meilleures pratiques de programmation. 

Du fait de son independance vis-a-vis de la plate -forme J2EE, il est utilisable sur tout 
type de developpement Java reposant sur J2SE. II convient aussi bien aux applications de 
type Web (grace a Spring MVC ou a son integration des principaux frameworks MVC) 
ou Swing (notamment grace au sous-projet Spring Rich Client). 
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Certains reprochent a Spring de ne pas etre un standard, a la difference de J2EE. Force 
est pourtant de constater qu'un developpement J2EE est souvent difficile a migrer d'un 
serveur d' applications a un autre, alors que les developpements qui utilisent Spring et 
s'abstiennent d'utiliser les EJB le sont beaucoup moins. Par ailleurs, Spring laisse le 
choix au developpeur du niveau d' adherence de son code vis-a-vis du framework, ce qui 
est moins le cas de J2EE. Par exemple, en n'utilisant que le conteneur leger et la POA, 
1' impact du remplacement de Spring par une autre solution est relativement faible. 

Presentation de I'etude de casTudu Lists 

Tout au long de l'ouvrage, nous illustrons notre propos au moyen d'une etude de cas, 
Tudu Lists, qui emploie les fonctionnalites majeures de Spring. Au travers de cette etude 
de cas, nous donnons une vision globale de 1' architecture d'une application fondee sur 
Spring, ainsi que de nombreux exemples de mise en oeuvre. 

Dans le contexte de cet ouvrage, nous utilisons une preversion 2.0 de Spring, la version 
finale n'etant pas disponible au moment oil nous mettons sous presse. L'API de Spring 
etant remarquablement stable, la version finale ne devrait pas introduire de dysfonction- 
nements majeurs. Si tel devait neanmoins etre le cas, un addendum precisant les change - 
ments a effectuer serait mis a la disposition des lecteurs sur la page Web dediee a 
l'ouvrage du site des editions Eyrolles, a l'adresse http://www.editions-eyrolles.com. 

Tudu Lists est un projet Open Source cree par Julien Dubois, l'un des auteurs du present 
ouvrage, et auquel les autres auteurs de l'ouvrage participent. Ce projet consiste en un 
systeme de gestion de listes de choses a faire ( todo lists) sur le Web. II permet de partager 
des listes entre plusieurs utilisateurs et supporte le protocole RSS (Really Simple Syndi- 
cation). Les listes de choses a faire sont des outils de gestion de projet simples mais effi- 
caces. Tudu Lists est heberge sur le site communautaire SourceForge (httpMudu.source- 
forge.net/) pour sa partie developpement. 

L'utilisation de Tudu Lists est tres simple comme nous allons le voir. La page d'accueil 
se presente de la maniere illustree a la figure 1 .2. 

Pour creer un nouvel utilisateur, il suffit de cliquer sur le lien « register » et de remplir le 
formulaire. Une fois authentifie, l'utilisateur peut gerer ses listes de todos. 

Par commodite, nous utilisons a partir de maintenant le terme « todo » pour designer une 
chose a faire, comme illustre a la figure 1.3. 

Pa le biais des onglets disposes en haut de la page, nous pouvons gerer notre compte (My 
info), nos listes de todos (My Todo Lists), nos todos (My Todos) ou nous deloguer (Log out). 

La creation d'une liste est on ne peut plus simple. II suffit de cliquer sur l'onglet My Todo 
Lists puis sur le lien Add a new Todo List et de remplir le formulaire et cliquer sur le lien 
Submit, comme illustre a la figure 1 .4. 

La creation d'un todo suit le meme principe. Dans l'onglet My Todos, il suffit de cliquer 
sur la liste dans laquelle nous allons ajouter un todo (les listes sont affichees dans la 
partie gauche de la page) puis de cliquer sur Add a new Todo. 
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Figure 1.2 Welcome Register 

Page d'accueil Tudu Lists 
de Tudu Lists 

Welcome to Tudu Lists! 



Tudu Lictc is on on-line opplicobon for monoging 
todo lists. 

Tudu Lists is a very simple application, which you 
can start using in seconds - but with some 
advantaqes over your home-made Excel todo list: 

• Tudu Lists is web- based, and accessible 
frnm anywhprp nn the planet. 

• Tudu Lists can be shared amonqst people: 
you can share lists with your friends, 
family or co-workers. 

• Tudu Libls can be accessed wiUi an RSS 
feed: if one of your shared lists is updated, 
your RSS aggregator will warn you. 

• Tudu Lists is completely free! Just 
register and start using It. 

• Even Tudu Lists' source code is free! If 
you want your very own install of Tudu 
Lists, or if you are a programmer and want 
to see how Tudu Lists is developped, just 
visit our developement Web site : 
http://tudu.sf.net. 



Login 



Login : 
Password : 



Remember me on this computer 
(30 days) □ 



I Login 1 1 Reset | 

You are not a Tudu Lists user yet? 
Just register. It's completely free. 

Did you forget your password? Click 
here to recover it. 



Figure 1.3 

Liste de todos 



My info My inrlniKrs My lodos lognnr 
Tudu Lists 



Welcome! 10/1) 





Welcomel 




I Add a new Todo J 








Description 


Priority Due date Completed Actions 


welcome to Tudu Lists! 


loo □ [ edit 1 Delete ] 


Backup * I Restore <t 



Figure 1.4 

Creation d'une 
liste de todos 



Add a new Todo List 



Description 

Allow RSS r 
publication? 

f Submit 1 f Cancel 1 
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Pour finir, nous pouvons sauvegarder le contenu d'une liste en cliquant sur le lien Backup. 
De meme, nous pouvons restaurer le contenu d'une liste en cliquant sur le lien Restore. 

Nous avons vu l'essentiel des fonctions de Tudu Lists. Pour une description plus detaillee 
de son utilisation, voir la documentation en ligne, sur le site http://tudu.sourceforge.net. 

Architecture du projet Tudu Lists 

Tudu Lists est une application Web, concue pour demontrer que l'utilisation de Spring et 
de frameworks specialises permet d'obtenir sans developpement lourd une application 
correspondant a l'etat de l'art en terme de technologie. 

Dans cette section, nous decrivons de maniere synthetique les principes architectu- 
raux de Tudu Lists. Ces informations seront utiles pour manipuler 1' etude de cas tout au long 
de l'ouvrage. 

Nous listons dans un premier temps les frameworks utilises par Tudu Lists puis abordons 
la gestion des donnees, notamment la modelisation de ces dernieres. Nous terminons 
avec les principes de la modelisation objet de Tudu Lists. 

Les frameworks utilises 

Outre Spring, Tudu Lists utilise les frameworks Open Source suivants : 

• Hibernate, le celebre framework de mapping objet-relationnel, pour assurer la persis- 
tance des donnees. 

• Struts, pour assurer 1' implementation du modele de conception MVC. Dans le cadre de 
cet ouvrage, nous proposons aussi une version speciale de Tudu Lists utilisant Spring 
MVC en lieu et place de Struts. 

• Struts Menu, pour gerer les menus de 1' application. 

• DWR (Direct Web Remoting) pour implementer les fonctionnalites AJAX (Asynchro- 
nous JavaScript And XML) de Tudu Lists. AJAX est une technologie fondee sur 
JavaScript destinee a ameliorer l'experience de l'utilisateur devant une interface homme- 
machine (IHM) en limitant les echanges entre le navigateur Web et le serveur d' appli- 
cations a des messages XML au lieu de pages Web completes. Nous aurons l'occasion 
de decrire plus en detail cette technologie au chapitre 9, consacre a AJAX et DWR. 

• Acegi Security, pour gerer les authentifications et les autorisations. 

• JAMon (Java Application Monitor), pour surveiller les performances de Tudu Lists. 

• Log4J, pour gerer les traces applicatives. 

• Rome, pour gerer les flux RSS. 

Comme nous le constatons, bien que Tudu Lists implemente des fonctionnalites simples 
a apprehender, il met en ceuvre un grand nombre de frameworks. 

Grace aux services rendus par ces differents frameworks et a l'integration assuree par 
Spring, le nombre de lignes de code de Tudu Lists reste raisonnable (3 200 lignes pour 
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une quarantaine de classes et interfaces, avec une moyenne de 6 lignes par methode) en 
comparaison de l'equivalent developpe uniquement avec J2EE. 

Modele conceptuel de donnees 

Tudu Lists utilise une base de donnees relationnelle pour stacker les informations sur les 
utilisateurs et les listes de todos. 

Le modele conceptuel de donnees de Tudu Lists s'articule autour de quelques tables, 
comme l'illustre la figure 1.5. 



todojist 


id 




name 




rss_allowed 




last_update 






0,n 




1,1 


todo 


M 




creationdate 




description 




priority 




completed 




completiondate 


due_date 









1,n 



0,n 




user 

login 

password 

enabled 

firstname 

last_name 

email 

creationdate 
last_access_date 

1,n 



user role 



0,n 




property 



pkev 
value 



Figure 1.5 

Modele conceptuel de donnees de Tudu Lists 



Remarquons que la table property sert a stacker les parametres internes de Tudu Lists, 
notamment l'adresse du serveur SMTP necessaire a l'envoi d'e-mail. Par ailleurs, la table 
role ne contient que deux lignes, chacune representant les deux roles geres par Tudu 
Lists : administrateur et utilisateur. 
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Pour implementer ce modele de donnees, nous utilisons le SGBDR Open Source 
HSQLDB (http://hsqldb.org/). A l'origine, Tudu Lists etait prevu pour fonctionner avec le 
SGBDR MySQL, mais nous avons remplace ce dernier pour simplifier 1' installation de 
l'etude de cas. En effet, HSQLDB est un SGBDR ecrit en Java, dont l'execution peut se faire 
au sein meme de l'application Web. II est done directement embarque dans 1' application, 
simplifiant grandement la problematique du deploiement. 

Pour utiliser Tudu Lists dans un environnement de production, nous conseillons d'utiliser 
la version de MySQL disponible sur le site de Tudu Lists, car ce SGBDR est prevu pour 
supporter de fortes charges, contrairement a HSQLDB. 



HSQLDB et MySQL 

Le remplacement de MySQL est facilite par I'architecture de Tudu Lists. Lessentiel du travail consiste a 
adapter le script SQL de creation des tables, celui de MySQL contenant des specificites propres a ce 
SGBDR. II suffit d'apporter ensuite des modifications a quelques fichiers de configuration portant sur la 
definition de la source de donnees et le reglage du dialecte SQL utilise par Hibernate. 



Les principes du modele objet 

Nous ne detaillons pas ici le modele objet de Tudu Lists, car il est decrit tout au long des 
chapitres de l'ouvrage. Ce modele suit la philosophic de conception preconisee par 
Spring, a savoir un decoupage clair des couches composant l'application. 

La figure 1.6 illustre les couches de Tudu Lists. 



Figure 1.6 

Couches de Tudu Lists 



Couche Web 



Filtres 


Services 




Actions 


DWR 




Struts 


Interfaces 




Formulaires 


obj. distants 




Struts 


Implement. 




obj. distants 





Couche securite 



Couche service 



Interfaces 



Implementations 



Couche domaine 




Modeles 






Interfaces DAO 






Implementations DAO 
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La couche domaine 

La couche domaine prend en charge le modele objet metier de Tudu Lists. C'est dans 
cette couche que nous trouvons les classes modelisant et implementant les notions de 
liste de todos, de todos, etc. 

Cette couche est constituee de trois sous-ensembles : 

• Le sous-ensemble des modeles contient les objets qui sont manipules par les autres 
couches de l'application. C'est dans ce sous-ensemble, offrant le plus haut niveau 
d' abstraction, que se trouvent les objets metier. 

• Le sous-ensemble des interfaces DAO contient les interfaces des DAO (Data Access 
Objects), qui specifient les services destines a assurer la persistance des objets metier. 

• Le sous-ensemble des implementations DAO contient les implementations des inter- 
faces precedentes. Dans le cadre de l'etude de cas, nous fournissons une implementation 
realisee avec Hibernate. 

Lutilisation des DAO est ainsi conforme au principe de Spring visant a separer les inter- 
faces des implementations. Bien entendu, les DAO de Tudu Lists reposent sur Spring 
DAO et Spring ORM. 

La couche service 

La couche service contient les services permettant de manipuler les objets metier du 
modele. Une nouvelle fois, les interfaces et leurs implementations sont clairement 
separees. 

Les services sont au nombre de quatre : 

• configuration de Tudu Lists ; 

• gestion des utilisateurs ; 

• gestion des listes de todos ; 

• gestion des todos. 

La couche securite 

La couche securite est assuree par le framework Acegi Security for Spring. Pour Tudu 
Lists, cette couche se resume a fournir une implementation d'un DAO permettant a Acegi 
Security d'acceder aux informations concernant les utilisateurs et de parametrer le 
framework via un fichier de configuration Spring. 

La couche Web 

La couche Web est constituee de plusieurs sous-ensembles : 

• Le sous-ensemble des filtres contient, comme son nom l'indique, les filtres (au sens 
J2EE du terme) utilises pour analyser les requetes HTTP. Tudu Lists possede les filtres 
suivants : filtre pour JAMon, filtre « session-in-view » et filtre Acegi Security. 
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• Les sous-ensembles des Actions Struts et des formulaires Struts contiennent les 
composants Web necessaires au framework Struts pour gerer 1'IHM de Tudu Lists. 

• Les sous-ensembles des services DWR des interfaces des objets distants et des imple- 
mentations des objets distants contiennent respectivement les services AJAX et les 
interfaces et implementations des objets metier disponibles pour ces services. 

Installation de I'environnement de developpement 

Pour les besoins de 1' etude de cas, nous avons limite au maximum les logiciels necessaires 
a son fonctionnement. 

Tudu Lists a simplement besoin des suivants : 

• Java 5 

• Eclipse 3. 1+, avec WTP 1 .0. 1+ (Web Tools Platform) 

• Tomcat 5.5+ 

Nous fournissons en annexe les instructions necessaires a leur installation. 

Nous supposons dans la suite de cette section que ces outils sont correctement installes 
sur le poste de travail. 

Installation de I'etude de cas 

L'etude de cas se presente sous la forme de cinq fichiers Zip, chacun contenant un projet 
Eclipse complet et independant des autres : 

• Tudu.zip : ce fichier contient le projet qui est utilise pour la majorite des chapitres de 
cet ouvrage. II s'agit d'une version legerement adaptee de Tudu Lists. 

• Tudu-SpringMVC.zip : ce fichier contient le projet utilise par les chapitres 7, 13 et 
16. II s'agit d'une version de Tudu Lists utilisant le framework Spring MVC au lieu de 
Struts. 

• Tudu-WebFlow.zip : ce fichier contient le projet utilise par le chapitre 8. II s'agit 
d'une version de Tudu Lists utilisant Spring Web Flow pour gerer sa couche presen- 
tation. 

• Tudu-Portlet.zip : ce fichier contient le projet utilise au chapitre 10. II s'agit d'une 
version de Tudu Lists transformee en portlet utilisable au sein d'un portail J2EE. 

• Tudu-Client.zip : ce fichier contient le projet utilise au chapitre 14. II s'agit d'une 
application Java Swing capable de communiquer avec 1' application Web Tudu Lists en 
utilisant un Web Service. 

II est possible de telecharger ces fichiers a partir soit de la page Web dediee a l'ouvrage 
du site des editions Eyrolles (http://www.editions-eyrolles.com). 
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L' installation des quatre premiers projets au sein d' Eclipse suit la me me procedure quel 
que soit le fichier. Nous decrivons ci-apres 1' installation du projet contenu dans le fichier 
Tudu.zip : 

1. Une fois le fichier telecharge, lancer Eclipse, puis creer un projet Web Dynamique 
par le biais du menu File/Project... en selectionnant 1' option Dynamic Web Project 
dans le dossier Web. 

2. Dans la boite de dialogue de creation de projet, definir le nom du projet (Tudu en 
respectant la majuscule) puis le serveur d' applications cible (en l'occurrence Tomcat) 
en cliquant sur le bouton New. Le serveur d' applications doit imperativement etre 
defini a cette etape, faute de quoi le projet ne se compilera pas. II est inutile de cocher 
la case Add Project to an EAR. 

3. Dans la boite de dialogue permettant de specifier les noms de repertoires du projet, 
changer src en JavaSource. 

4. Importer le fichier Zip via les menus File et Import. 

5. Dans la fenetre d' importation, selectionner le type Archive File, et cliquer sur le 
bouton Next. 

6. Dans la fenetre de selection, cliquer sur le bouton Browse en haut de la fenetre afin de 
selectionner le fichier Zip sur le disque dur. 

7. Cliquer sur le bouton Finish. 

8. Pour recompiler le projet, selectionner Project et Clean, puis choisir le projet Tudu et 
cocher la case Start a build immediately. 

9. Si des problemes de compilation apparaissent, s'assurer que le projet utilise bien le 
compilateur Java 5 (les proprietes du projet sont accessibles via son menu contextuel). 

10. Pour terminer, exporter les fichiers hsqldb- 1.8.0.1. jar et jta.jar depuis la racine du 
projet dans le repertoire common/lib du repertoire d' installation de Tomcat. Pour 
cela, selectionner les fichiers dans la vue et utiliser le menu contextuel Export. . . 

Une fois l'operation terminee, il est possible de configurer et d'executer chaque projet, 
comme explique a la section suivante. 

Pour Tudu-Client, la procedure est plus simple. II suffit d'utiliser le menu File/Import. . . , 
de selectionner Existing Projects into Workspace et de cliquer sur Next. Dans la boite de 
dialogue d'import, il faut ensuite selectionner l'option Select archive file puis cliquer sur 
Browse. . . pour choisir le fichier Tudu-Client.zip. Pour achever, l'importation du projet, 
cliquer sur Finish. 

Configuration et execution de I'application 

Une fois I'application Tudu Lists installee, il faut configurer la connexion a la base de 
donnees puis tester son bon fonctionnement. Le projet Tudu-Client ne contenant pas 
I'application Tudu Lists mais une simple application Swing, il n'est pas concerne par ce 
qui suit. 
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La base de donnees de Tudu Lists est installee dans le repertoire db de chaque projet 
Eclipse : 

1. Pour connaitre le chemin physique de ce repertoire sur le disque dur, selectionner par 
clic droit le dossier db, et cliquer sur Properties dans le menu contextuel. 

2. Dans la fenetre qui s'affiche, le chemin physique est fourni sous le nom Location. 
Memoriser ce chemin, car il sera necessaire pour configurer la connexion a la base. 

3. Fermer la fenetre. 

4. Pour configurer la connexion, editer le fichier context.xml, qui se trouve dans le 
repertoire WebContent/META-INF du projet. Ce fichier se presente de la maniere 
suivante : 

<?xml version='1.0' encoding='utf-8'?> 
<Context> 

<Resource auth="Container" description="Tudu database" 
dri verClassName="org.hsqldb. jdbcDriver" 
maxActive="100" maxldle="30" 
maxWait="10000" name=" jdbc/tudu" password="" 
type="javax.sql .DataSource" 

url="jdbc:hsqldb:C:\Eclipse\workspace\tudu\db\tudu" 

username="sa" 

/> 

</Context> 

5. Remplacer le texte en gras par le chemin physique de la db en veillant a ne pas 
supprimer le tudu final. 

Nous pouvons maintenant executer Tudu Lists dans Tomcat (les etapes qui suivent ne 
sont pas valables pour le projet Tudu-Portlet, qui doit s' executer dans un portail ; la 
procedure dependant du portail utilise, nous ne la decrivons pas) : 

1. Pour lancer le projet Tudu-SpringMVC, il est necessaire de lancer prealablement le 
script build.xml, qui se trouve a la racine du projet. Pour cela, il suffit de le selection- 
ner dans la vue Package Explorer et d'utiliser le menu contextuel Run As/ Ant Build. 
Ce script lance le logiciel ActiveMQ, necessaire specifiquement pour ce projet. 

2. Pour lancer Tomcat, acceder au menu contextuel du projet par clic droit sur son 
dossier dans la vue Package Explorer. 

3. Dans ce menu, selectionner Run As et Run on Server puis Tomcat dans la liste des 
serveurs disponibles et cliquer sur Next. 

4. II convient de s'assurer que le projet se trouve bien dans la zone Configured Projects 
en utilisant au besoin le bouton Add et en cliquant sur Finish. 

Tomcat s'execute, et une fenetre de navigation Web s'affiche dans Eclipse avec la page 
d'accueil de Tudu Lists (voir figure 1.2). Dans le cas du projet Spring-WebFlow, l'inter- 
face presentee a ete fortement simplified pour les besoins du chapitre 8. 
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Nous pouvons maintenant nous connecter a Tudu Lists en utilisant l'identifiant test et le 
mot de passe test. 



Organisation des projets dans Eclipse 

La figure 1.7 illustre 1' organisation des projets (a l'exception de Tudu-Client) telle 
qu'elle doit apparaitre dans l'environnement Eclipse. 



Figure 1.7 

Organisation des projets 
Tudu Lists dans Eclipse 
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Le repertoire JavaSource contient 1' ensemble du code de Tudu Lists. II comprend aussi 
les fichiers de configuration d' Hibernate et de Log4J. 

Le repertoire Tests contient l'ensemble des tests unitaires de Tudu Lists. Le repertoire db 
contient pour sa part la base de donnees de 1' application. 

Le repertoire WebContent dispose de plusieurs sous-repertoires : 

• ess contient la feuille de style utilisee par Tudu Lists. 

• images contient l'ensemble des images du projet. 

• META-INF contient le fichier de parametrage de la connexion a la base de donnees. 

• scripts contient les fichiers JavaScript necessaires a 1'IHM. 

• WEB-INF contient les fichiers de configuration de 1' application Web, ainsi que les 
pages et fragments JSP (respectivement dans les sous-repertoires jsp et jspf) et les taglibs 
(sous-repertoire tld). 

Conclusion 

Ce chapitre a introduit les grands principes de fonctionnement de Spring et decrit ses 
apports fondamentaux au developpement d' applications Java/J2EE, que ces dernieres 
utilisent ou non des frameworks tiers. II a aussi presente l'etude de cas Tudu Lists, qui 
guidera le lecteur tout au long de sa progression dans l'ouvrage. 

Au cours des deux chapitres suivants, nous plongeons au cceur de Spring afin de mettre 
en valeur les notions essentielles de conteneur leger et de POA, qui en forment l'ossature. 

Le reste de l'ouvrage est consacre aux principales integrations de frameworks tiers 
proposees par Spring et aux outils permettant d'accelerer les developpements avec Spring. 
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Comme indique au chapitre 1 , Spring est bati sur deux piliers : son conteneur leger et 
son framework de POA. 

Pour utiliser Spring de maniere efficace dans nos developpements et beneficier pleine- 
ment de sa puissance, il est fondamental de bien comprendre les concepts lies a ces 
deux piliers et de modeliser nos applications en consequence. 

L'objectif de cette partie est double : fournir les bases conceptuelles necessaires a la 
bonne mise en ceuvre de Spring et initier a l'utilisation de son conteneur leger et de son 
framework de POA. 

Le chapitre 2 fournit les bases conceptuelles des conteneurs legers et illustre leur 
valeur ajoutee au travers d'une etude de cas fondee sur l'application Tudu Lists. 

Le chapitre 3 fait le lien entre les aspects fondamentaux des conteneurs legers et leur 
implementation par Spring. 

Sur le modele du chapitre 2, le chapitre 4 fournit les bases conceptuelles de la POA en 
reprenant l'etude de cas precedente. L'objectif de ce chapitre n'est pas d'etre exhaustif 
sur le sujet mais de presenter les notions essentielles de la POA. 

Construit sur le modele du chapitre 3, le chapitre 5 montre comment Spring imple- 
mente les notions essentielles de la POA et en tire parti pour fournir aux applications 
des fonctionnalites a valeur ajoutee sans intrusivite. 
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Les concepts 
des conteneurs legers 



Les conteneurs legers sont devenus tres populaires ces dernieres annees. Au chapitre 
precedent, nous avons donne les principales raisons expliquant cet engouement. Dans le 
present chapitre, nous decrivons les concepts qui sous-tendent les conteneurs legers et 
font tout leur interet par rapport aux techniques classiques de developpement. 

Pour bien comprendre l'interet des conteneurs legers, nous abordons la conception d'un 
modele metier simpUfie de 1' application Tudu Lists selon differents points de vue concep- 
tuels, allant du plus naif au plus evolue, en faisant ressortir leurs faiblesses respectives. 

Nous verrons ensuite comment les conteneurs legers repondent aux problemes de concep- 
tion souleves par ces differentes approches et detaillerons les notions d' inversion de controle 
et d'injection de dependances, qui sont au fondement des conteneurs legers. 

Problematiques de conception d'une application 

Pour concevoir une application, plusieurs approches sont possibles. Une premiere appro- 
che consiste a se concentrer sur le besoin immediat sans se preoccuper de l'avenir. C'est 
ce que nous appelons l'approche naive. 

Une approche plus mature consiste a utiliser les services offerts par la technologie pour 
gagner en productivite. Malheureusement, la technologie n'est pas suffisante en elle-meme 
pour lutter contre les defauts de conception compromettant la perennite de 1' application. 
Nous nous placons volontairement ici dans le cadre d' applications a forte longevite. 

La troisieme approche respecte les regies de l'art en s'appuyant sur des modeles de 
conception, ou design patterns, eprouves, tels ceux proposes par le Gang of Four 
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(Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides) dans leur celebre 
ouvrage Design patterns : catalogue de modeles de conception reutilisables . 

Nous tenterons d'appliquer ces differentes approches pour creer une version volontaire- 
ment simplified du modele metier de Tudu Lists arm de faire ressortir les problemes 
conceptuels qu'elles soulevent. 

Pour pouvoir analyser les defauts de ces approches, il est necessaire de se doter de criteres 
objectifs permettant de les comparer a un modele ideal, lequel n'existe malheureusement pas. 

Dans son article The Depency Inversion Principle, publie dans le magazine C+ + Report, 
Robert Cecil Martin propose les trois criteres suivants pour identifier les faiblesses d'une 
modelisation : 

• Rigidite : les changements dans 1' application sont difhciles a effectuer, car ils affectent 
trop de composants du systeme. 

• Fragilite : lorsque des changements sont operes dans 1' application, des erreurs inattendues 
se produisent. 

• Immobilite : il est difficile de reutiliser les composants dans une autre application, car 
ils ne peuvent fonctionner independamment les uns des autres. 

Pour completer ces trois criteres, nous en utilisons un quatrieme, Vinverifiabilite, qui 
pose que les composants du modele ne peuvent etre verifies selon differents niveaux de 
granularite (tests unitaires, tests d' integration, tests des interfaces, etc.). 

Perimetre de la modelisation 

Avant de nous lancer dans la conception du modele metier de Tudu Lists, commencons 
par decrire les besoins fonctionnels a couvrir. II ne s'agit pas de concevoir 1' ensemble de 
P application mais de nous interesser a un sous-ensemble de besoins suffisamment signi- 
ficatifs pour faire ressortir les faiblesses des differentes approches. 

Nous allons modeliser les deux notions fonctionnelles de Tudu Lists, a savoir les todos 
et les listes de todos. Nous faisons ici abstraction de la notion d'utilisateur, de la securite, de 
la gestion des transactions, etc. Nous ne nous interessons pas non plus aux problema- 
tiques d'lHM et nous concentrons exclusivement sur la modelisation des todos et de 
leurs listes, ainsi que des fonctions permettant de gerer ces deux entites. 

Dans ce contexte fonctionnel simplifie a 1' extreme, les todos se presentent sous la forme 
d'une structure de donnees comportant les informations suivantes : 

• identifiant ; 

• date de creation ; 

• description ; 

• priorite ; 

• indicateur de realisation de la chose a faire ; 

• date de realisation prevue ; 

• date de realisation effective. 
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Les listes de todos ne comportent pour leur part qu'un identifiant, un nom et une liste de 
todos. 

Le modele metier devra proposer les fonctionnalites classiques de creation, suppression, 
modification et consultation, generalement identifiees par l'acronyme CRUD (Create, 
Retrieve, Update, Delete). 

Pour assurer la persistance de ce modele, une base de donnees relationnelle est utilisee, 
dont la modelisation conceptuelle est illustree a la figure 2. 1 . 
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id 

creation_date 

description 

priority 
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completion_date 
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Figure 2.1 

Modele conceptuel de la base de donnees de Tudu Lists 



Approche naive 

Comme indique en debut de chapitre, 1' approche naive consiste a se focaliser sur les 
besoins immediats sans se preoccuper de l'avenir de 1' application. 

Modelisation 

A partir du modele conceptuel de la base de donnees, il est naturel pour cette approche de 
proposer un modele metier comprenant deux classes calquant les entites todojist et 
todo, comme l'illustre le diagramme de classes UML de la figure 2.2. 



Figure 2.2 

Diagramme de classes 
de V approche naive 



TodoList 


- todos 


Todo 


-id 

-name 


-id 

-creation Date 

-description 

-priority 

-completed 

-completion Date 
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+save() 

+remove() 

+update() 

+listTodoLists() 

+listTodos() 

+addTodo() 

+removeTodc() 

+getTodo() 


> 
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+save() 

+remove() 

+update() 



Sur ce schema UML simplifie, nous n'avons fait figurer ni les accesseurs (getters) et 
modificateurs (setters) des attributs des deux classes ni les constructeurs. 
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Dans cette conception, la classe TodoList est la porte d'acces aux deux notions fonction- 
nelles evoquees a la section precedente. Outre ses propres proprietes, TodoList pilote la 
classe Todo en lui sous-traitant les aspects strictement specifiques aux todos. 

Critique de la modelisation 

Pour critiquer cette modelisation, utilisons les quatre criteres d' analyse decrits prece- 
demment : 

• Rigidite. La classe TodoList est etroitement liee a la classe Todo, puisqu'elle prend 
directement en charge leur gestion (ajout, suppression, consultation). Ces operations 
ensemblistes alourdissent le code de TodoList alors qu'elles pourraient etre prises en 
charge par d'autres classes plus generiques, comme les Li st de 1' API Java. Ce choix de 
conception impose une representation interne du stockage des todos, rendant le code 
rigide des lors que cette representation ne s'avere plus adaptee. Par ailleurs, les fonc- 
tionnalites riches proposees par les deux classes encouragent les mauvaises pratiques. 
En l'occurrence, il est tentant de disperser dans les differentes couches de l'application 
finale l'appel aux methodes de gestion des listes et de leurs todos. Ce type de mauvaise 
pratique rend le code plus rigide, car toute modification sur ces fonctionnalites impacte 
un grand nombre de compos ants. 

• Fragilite. Nous constatons un melange entre les notions strictement fonctionnelles que 
sont les todos et leurs listes, d'une part, et la problematique de leur gestion, en l'occur- 
rence leur persistance, d' autre part. Cette absence de separation des preoccupations 
aboutit a des effets de bord. Par exemple, si un todo n'est pas enregistre en base de 
donnees, il est necessaire de passer en revue a la fois la gestion des todos dans la classe 
TodoList et le code de la classe Todo. 

• Immobility. Les classes TodoLi st et Todo supposent la presence d'une base de donnees 
relationnelle. Si le besoin exprime aujourd'hui est bien d'avoir un SGBDR pour 
assurer la persistance de donnees, nous pouvons tres bien imaginer une version de 
Tudu Lists pour telephone mobile. Dans ce cas, l'utilisation d'un SGBDR n'est pas 
forcement le choix le plus judicieux, ce type de terminal ayant des capacites limitees. 
II nous faut done developper une nouvelle version de ces deux classes pour supporter 
ces nouveaux besoins, nous privant ainsi de toute reutilisation des autres services inde- 
pendants de la persistance proprement dite. 

• Inverifiabilite. II est clair qu'une conception aussi rigide, fragile et immobile ne 
facilite pas les tests. Les classes TodoList et Todo melangeant differentes preoccupa- 
tions fonctionnelles (manipulation des notions fonctionnelles) et techniques 
(persistance de donnees dans un SGBDR), les tests unitaires sont impossibles, 
puisque nous ne pouvons faire fonctionner ces deux classes independamment de 
1' infrastructure technique necessaire a l'ensemble de l'application, en l'occurrence 
le SGBDR. La granularite la plus fine en terme de tests est fournie par les tests 
d' integration, a la fois couteux a realiser et peu efficaces pour detecter les erreurs 
d' implementation simples. 
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En resume 

Nous pouvons constater que l'approche naive, bien que proposant une solution simple et 
immediate a notre besoin de gerer des listes de todos, n'est pas satisfaisante du point de 
vue conceptuel, comme le montre 1' analyse de nos quatre criteres. 

Cette modelisation s'avere rigide, fragile et immobile du fait d'une modularisation insuf- 
fisante des problematiques techniques. Cette mauvaise modularisation a un impact direct 
sur l'inverifiabilite de 1' application, puisque ses composants ne peuvent etre testes effica- 
cement de maniere unitaire. 



Approche technologique 

L'approche technologique va plus loin que l'approche naive en ce qu'elle s'appuie sur les 
fonctionnalites de la plate-forme J2EE pour gagner en productivity dans 1' implementation 
des notions metier. 

Fondamentalement, la conception reste la meme mais prend en compte le modele de 
composants metier de J2EE. 

Modelisation 

Les EJB (Enterprise JavaBeans) du standard J2EE ont pour vocation d'implementer les 
objets metier d'une application. II est done naturel de s'y interesser pour 1' implementation 
des todos et de leurs listes. 

Les EJB peuvent etre de differents types. Les EJB Session implementent les traitements 
fonctionnant selon un mode conversationnel, avec ou sans etat. Les EJB Entite imple- 
mentent les objets metier persistants. Quant aux EJB Message, ils implementent les 
traitements fonctionnant en mode asynchrone. 

Dans le cas qui nous interesse, il est evident que les EJB Entite repondent a nos attentes. 
Le modele de donnees etant simple, nous utilisons des EJB Entite CMP (Container 
Managed Persistence), dont la persistance est geree par le conteneur, a la difference des 
EJB BMP (Bean Managed Persistence), geres par programmation. 

Lutilisation des EJB Entite aboutit au diagramme UML illustre a la figure 2.3. 

Nous avons ici deux EJB Entite, que nous considerons comme etant de type CMP : 

• TodoListBean, qui represente la notion fonctionnelle de liste de todos. 

• TodoBean, qui represente la notion fonctionnelle de todo. 

La principale evolution de ce modele par rapport a celui de l'approche naive est que le 
code des objets metier est expurge des traitements lies a la persistance des donnees, ceux- 
ci etant pris en charge directement par le conteneur d'EJB du serveur d' applications. 

La modelisation s'est complexifiee afin de supporter le fonctionnement du conteneur : les clas- 
ses TodoLi stBean et TodoBean sont abstraites (contrainte imposee aux EJB CMP), et differentes 
interfaces doivent etre definies pour chaque EJB afin de permettre aux clients d'y acceder. 
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«interface» 
javax.ejb.EntityBean 



TodoList 



entityContext 
id 

name 



+getEntityContext() 

+setEntityContext() 

+ unsetEntityContext() 

+ejbActivate() 

+ejbPassivate() 

+ejbCreate() 

+ejbPostCreate() 

+ejbLoad() 

+ejbStore() 

+ejbRemove() 



-- todos 



Todo 



-entityContext 
-id 

-creationDate 

-description 

-priority 

-completed 

-completionDate 

dueDate 



+getEntityContext() 

+setEntityContext () 

+unsetEntityContext () 

+ejbActivate() 

+ejbPassivate() 

+ejbCreate() 

+ejbPostCreate() 

+ejbLoad() 

+ejbStore() 

+ejbRemove() 



Figure 2.3 

Diagramme de classes de I'approche technologique 



«interface» 
javax.ejb.EJBLocalHome 





«interface» 
TodoList LocalHome 


«interface» 
TodoLocalHome 
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«interface» 
javax.ejb.EJBLocalObject 



«interface» 
TodoListLocal 



+getld() 

+setld() 

+getName() 

+setName() 

+getTodos() 

+setTodos() 



«interface» 
TodoLocal 



+getld() 
+setld() 

+getCreationDate() 

+setCreationDate() 

+ getDescription ( ) 

+setDescripttan() 

+getPriority() 

+setPriority() 

+getCompleted() 
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Nous ne faisons apparaitre ici que les interfaces locales. Les interfaces distantes sont 
similaires aux exceptions pres et derivent de javax.ejb.EJBObject et javax.ejb. EJBHome. 

Pour beneficier au maximum de la puissance des EJB, nous avons choisi de faire gerer 
par le conteneur la relation entre l'EJB TodoList et l'EJB Todo. 
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Critique de la modelisation 

Comme indique precedemment, l'approche technologique ne revolutionne pas la mode- 
lisation naive mais solutionne un certain nombre de problemes en deleguant la gestion de 
la persistance au conteneur d'EJB. 

A l'egard de nos quatre criteres d' analyse, nous pouvons adresser les critiques suivantes 
a la modelisation : 

• Rigidite. La situation est amelioree par rapport a la precedente, car la gestion de la 
relation entre TodoListBean et TodoBean est directement prise en charge par le conteneur 
d'EJB, allegeant ainsi le code de TodoListBean. Les todos sont represented dans la 
classe TodoLi stBean sous la forme d'une collection (au sens Java du terme). Malheureu- 
sement, la prise en charge par le conteneur d'EJB de la problematique de la persistance 
ne corrige en rien le probleme de la richesse fonctionnelle de ces deux classes, lequel 
encourage les mauvaises pratiques, comme nous l'avons montre avec l'approche 
naive. 

• Fragilite. Le bilan est mitige. D'un cote, nous beneficions d'une meilleure separation 
des preoccupations, le conteneur d'EJB prenant a sa charge, moyennant parametrage 
dans le fichier ejb-jar.xml, toute la problematique de la persistance. Mais d'un autre 
cote, les EJB ne sont pas aussi facilement accessibles que des classes Java standards. 
De ce fait, les classes clientes des EJB doivent se doter de traitements techniques 
specifiques pour acceder aux EJB (acces a l'annuaire JNDI, etc.). 

• Immobility. La situation est deterioree : les EJB requierent non seulement la presence 
d'une base de donnees relationnelle mais aussi celle d'un serveur d' applications J2EE 
dote d'un conteneur d'EJB. La reutilisation dans des contextes techniques differents 
est done compromise. 

• Inverifiabilite. Pas d' amelioration non plus : 1' infrastructure technique necessaire 
pour tester les deux notions fonctionnelles de notre etude de cas est preponderante. 
Nous ne pouvons toujours pas en faire abstraction lors des tests, rendant impossibles 
les tests unitaires. 



En resume 

Fondamentalement, la conception de l'approche technologique reste la meme que 
celle de l'approche naive. Elle herite done d'une grande partie des defauts de cette 
derniere. 

Si la situation s'est amelioree en terme de separation des preoccupations du fait de la 
prise en charge de la persistance par le conteneur EJB, elle s'est en revanche degradee en 
terme de reutilisation. L application repose entierement sur le modele EJB, ce qui impli- 
que necessairement la presence d'un serveur d' applications en plus de la base de 
donnees. 
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Approche par les modeles de conception 

L'approche par les modeles de conception se veut plus mature que les deux precedentes 
en ce qu'elle repose sur des modeles generiques eprouves et formalises. 

La technologie retrouve ici sa vraie place par rapport a la modelisation : elle devient un 
moyen et non une finalite. 

Modelisation 

Avant d'identifier les modeles de conception qui nous seront utiles, il est important de 
preciser des a present les fondations de notre modelisation. Celles-ci sont constituees de deux 
piliers principaux : 

• Separation claire entre les notions fonctionnelles manipulees par 1' application, leur 
gestion et leur persistance. L'idee est d'ameliorer la reutilisation et revolution des 
services autour des notions fonctionnelles. II s'agit done d'une architecture en couches : 
une couche modele contenant les notions fonctionnelles, une couche service contenant 
les gestionnaires de todos et de leurs listes et une couche de persistance. 

• Separation claire entre les interfaces et les implementations pour rendre transparentes 
les modifications des implementations qui n'impactent pas les interfaces. 

A partir de ces deux choix fondamentaux, nous pouvons selectionner les modeles de 
conception, ou design patterns, suivants : 

• La fabrique (factory) : ce modele de conception permet d'associer une implementation 
a une interface. En effet, si nous desirons rendre notre application independante des 
implementations, il est necessaire de faire appel a une classe specifique, la fabrique, 
qui saura instancier 1' implementation correspondant a une interface donnee. 

• Le singleton : ce modele de conception definit des classes n'ayant qu'une seule 
instance pour l'ensemble de 1' application. Cela sera le cas notamment des fabriques 
precedemment evoquees, puisqu'il y a plus de desagrements que d'interet en terme de 
ressources d'en avoir plusieurs instances. 

• L'objet d'acces aux donnees, ou DAO (Data Access Object) : ce modele de conception 
isole la problematique de l'acces aux donnees dans des classes prevues exclusivement 
a cet effet. Nous evitons ainsi la proliferation du code d'acces aux donnees au sein de 
1' application en le concentrant dans quelques classes specialisees, plus faciles a gerer. 

Forts de ces choix de conception, nous pouvons proposer la modelisation illustree a la 
figure 2.4. 

Pour les besoins de la conception, nous avons defini un stereotype UML « singleton » pour 
denoter les classes implementant le modele de conception singleton. Nous n' avons pas 
represente 1' implementation de ce design pattern au sein des classes puisqu'il s'agit davan- 
tage d'une problematique de codage que de conception, comme nous le verrons plus loin. 

Les fleches en pointilles montrent les relations d'utilisation des implementations se 
substituant aux relations physiques concernant leurs interfaces. 
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Figure 2.4 

Diagramme de classes de Vapproche par les modeles de conception 
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Nous remarquons que les deux piliers de notre conception ont abouti aux resultats 
suivants : 

• Les deux classes Todo et TodoList sont expurgees des problematiques associees a leur 
gestion. II s'agit done de la materialisation des deux notions fonctionnelles, sans inter- 
ference de la part de la technique. 

• La gestion des todos et de leurs listes se materialise sous forme de deux types de 
classes : les classes « managers » assurant la gestion et les classes « DAO » prenant en 
charge la communication avec le support de stockage. 

• Du fait de la separation systematique entre les interfaces et les implementations des 
classes « managers » et « DAO », nous avons cree des fabriques permettant d'associer 
a chacune des interfaces 1' implementation correspondante. 

Nous avons choisi de separer la notion de manager de la notion de DAO afin d'ameliorer 
la separation des preoccupations au sein de notre modele. Les DAO sont exclusivement 
reserves a l'acces aux donnees, les managers prenant en charge des problematiques de 
plus haut niveau, comme la securite et les transactions. Les DAO pourront etre imple- 
mented de plusieurs manieres sans impacter le reste de 1' application, par exemple, sous 
forme d'appels JDBC classiques, d'EJB ou encore d'appels a un framework de mapping 
objet-relationnel. 

Nous constatons aussi que les classes metier TodoList et Todo n'ont pas d'interface sepa- 
ree de leur implementation. Cela se justifie par le fait qu'il n'y a aucun interet pratique a 
fournir des implementations differentes pour des classes metier qui s'averent etre de 
simples structures de donnees. 

De meme, les fabriques ne possedent pas d'interface distincte de leur implementation 
pour la bonne raison que, dans le cas contraire, celles-ci devraient beneficier d'une fabrique, 
ce qui n' apporterait aucune valeur ajoutee au modele. 

Critique de la modelisation 

Une critique qui vient immediatement a l'esprit lorsque nous comparons cette modelisa- 
tion avec les approches precedentes est qu'elle fait intervenir un plus grand nombre de 
classes et d' interfaces, rendant le modele un peu plus complexe a comprendre et le code 
plus long a ecrire. 

Cependant, si nous nous attachons aux quatre criteres d' analyse que nous avons definis, 
nous constatons que la situation s'ameliore tres nettement : 

• Rigidite. La separation claire des preoccupations permet de faire evoluer les proble- 
matiques techniques telles que la persistance des donnees de maniere transparente 
vis-a-vis des classes metier. De meme, les classes « managers » peuvent offrir de 
nouveaux services ou implementer de nouveaux controles sans mettre en cause les classes 
metier. 

• Fragilite. Chaque couche etant clairement isolee des autres, du moment que les 
contrats fixes par les interfaces sont respectes, revolution des implementations associees 
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se deroule de maniere totalement transparente et ne cree normalement pas d'effets de 
bord sur le reste du code. 

• Immobility. La situation est la aussi nettement amelioree du fait de 1' architecture en 
couches et de la separation claire des interfaces. Les classes metier sont reutilisables 
quel que soit le contexte technique sous-jacent. Les classes managers et DAO peuvent 
evoluer dans leur implementation pour s' adapter au contexte technique, comme 1' utili- 
sation d'un fichier XML au lieu d'un SGBDR pour la persistance, sans pour autant 
remettre en cause leurs interfaces, et done le modele dans son integralite. 

• Inverifiabilite. Nous pouvons enfin tester chaque classe independamment des autres. 
En effet, les classes TodoList et Todo se suffisent a elles-memes, puisqu'elles n'ont 
aucune dependance technique, et peuvent done etre testees unitairement. De meme, les 
classes managers peuvent etre testees de maniere unitaire en remplacant 1' implemen- 
tation des DAO utilisant le SGBDR par des « objets simulacres », ou mock objects, 
developpes specifiquement pour les tests a l'aide de frameworks tels qu'EasyMock, 
qui facilitent grandement leur creation. Pour cela, il est necessaire de modifier les 
fabriques de maniere qu'elles generent des simulacres et non des implementations 
reelles. 

En resume 

Lutilisation des design patterns a permis d'augmenter de maniere significative la qualite 
de note conception pour tous nos criteres d'analyse. Cette qualite s'obtient cependant au 
prix d'une plus grande complexite de conception du fait de 1' implementation des design 
patterns. 

Bilan des differentes approches 

Comme nous venons de le voir, la technologie seule ne suffit pas pour batir un modele 
evolutif et testable. En se fondant sur l'experience des meilleurs experts, l'approche par 
modele de conception parvient a ameliorer significativement la situation. 

Cependant, si nous observons le modele de conception de cette derniere approche, nous 
pouvons nous interroger sur la possibility d'implementer de maniere generique, et done 
reutilisable, les fabriques et les singletons, et plus generalement le cycle de vie des 
objets. En effet, leur mode de fonctionnement ne varie pas en fonction des interfaces et 
des implementations. 

Plus generalement, la gestion des dependances entre les objets reste encore presente dans 
le code, en partie prise en charge par les fabriques. Plusieurs dependances sont gerees au 
sein des classes mais ne sont pas visibles au niveau conceptuel, a l'exemple des sources 
de donnees necess aires aux DAO. 

Ce sont ces problemes que proposent de resoudre les conteneurs legers, dont nous allons 
etudier les mecanismes dans les sections suivantes. 
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L'inversion de controle 

Les conteneurs legers sont aussi souvent appeles conteneurs d' inversion de controle, 
ou IoC (Inversion of Control) Container. Avant d'etudier le fonctionnement de ces 
conteneurs, il est important de bien comprendre ce qu'est le concept d'inversion de 
controle. 

Par controle, nous entendons le controle du riot d'execution d'une application. Comme 
nous le verrons, l'inversion de controle est un concept generique ancien, que Ton rencontre 
dans des solutions logicielles autres que les conteneurs legers. Nous montrerons que 
l'inversion de controle proposee paries conteneurs legers s'avere etre une version specia- 
lised de cette notion. 



Controle du flot d'execution 

Lorsque nous programmons de maniere procedurale, nous maitrisons totalement le flux 
d'execution de notre programme via des instructions, des conditions et des boucles. C'est 
generalement le cas au sein d'une methode, par exemple. 

Si nous considerons une application utilisant Swing (l'API graphique standard de Java), 
par exemple, nous ne pouvons pas dire que le flot d'execution est maitrise de bout en 
bout par 1' application. En effet, Swing utilise un modele evenementiel qui declenche les 
traitements de 1' application en fonction des interactions de l'utilisateur avec 1'IHM (clic 
sur un bouton, etc.). 

En nous reposant sur Swing pour declencher les traitements de 1' application, nous 
operons une inversion du controle du flot d'execution, puisque ce n'est plus notre 
programme qui se charge de le controler de bout en bout. Au contraire, le programme 
s'insere dans le cadre de fonctionnement de Swing (son modele evenementiel) en « atta- 
chant » ses differents traitements aux evenements generes par Swing suite aux actions de 
l'utilisateur. 

La figure 2.5 illustre 1' effet de l'inversion de controle sur le flot d'execution. 



Inversion de controle : frameworks et bibliotheques logicielles 

Comme le fait remarquer Martin Fowler dans son celebre article sur les conteneurs legers (voir references 
en annexe), l'inversion de controle est un principe qui permet de distinguer les frameworks des bibliothe- 
ques logicielles. 

Les bibliotheques sont de simples boTtes a outils, dont les fonctions s'inserent dans le flot d'execution du 
programme. II n'y a done pas d'inversion de controle. A I'inverse, les frameworks prennent a leur charge 
I'essentiel du flot d'execution dans leur domaine de specialite, le programme devant s'inserer dans le 
cadre qu'ils fixent. 



Ainsi, le principe de l'inversion de controle est au moins aussi ancien que celui de la 
programmation evenementielle. II s'agit d'un principe generique utilise par de nombreux 
frameworks apparus bien avant la notion de conteneur leger. L'inversion de controle est 
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aussi appelee principe « Hollywood » en reference a la phrase mythique « ne nous appelez 
pas, nous vous appellerons ». 

Dans le cas du framework Web Struts, il est evident qu'il implemente une inversion de 
controle puisqu'il se charge d'appeler lui-meme les actions de I'application en fonction 
des requetes envoyees par les navigateurs Web. Cependant, cette inversion de controle est 
limitee a la couche de presentation, comme nous le verrons au chapitre 6, dedie a 1' inte- 
gration de Struts par Spring. 

De la meme maniere, les conteneurs d'EJB implementent une inversion de controle puis- 
que la gestion du cycle de vie des EJB (via les methodes ejbActivate, ejbPassivate, etc.) 
ainsi que l'appel a leurs differentes methodes sont pris en charge directement par le 
conteneur. 

Maintenant que nous connaissons la signification de 1' inversion de controle et ses 
nombreuses implementations, nous pouvons nous interroger sur la nouveaute introduite 
par les conteneurs legers en la matiere. 
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L'inversion de contrdle au sein des conteneurs legers 

Les conteneurs legers proposent une version specialised de l'inversion de controle. lis se 
concentrent en fait sur le probleme evoque plus haut de la gestion des dependances entre 
objets et leur instanciation, notamment dans le cadre d'une dissociation des interfaces et 
des implementations. 

Si nous reprenons notre etude de cas, la modelisation proposee par l'approche par les 
modeles de conception est la meilleure selon nos criteres d' appreciation (rigidite, fragi- 
lite, immobility et inverifiabilite). Cependant, si nous la comparons a l'approche naive, 
nous constatons que ce gain s'effectue au detriment de la taille et de la complexite du 
code : la flexibilite du modele a un cout. 

Dans notre cas, ce cout est assez faible. Les classes et interfaces etant peu nombreuses, 
leurs dependances sont facilement gerables. Cependant, si nous envisageons ce type de 
modelisation pour une application plus complexe, il devient evident que le grand nombre 
de fabriques va rapidement poser probleme en terme de gestion. II est done interessant de 
chercher une solution de rechange a cette multitude de fabriques, d'autant qu'elles fonc- 
tionnent toutes selon le meme modele, qui consiste a associer une implementation X a 
une interface Y a la demande d'une classe utilisatrice. De meme, bien que les singletons 
fonctionnent tous selon le meme principe, quelle que soit la classe considered, ils doivent 
etre implemented systematiquement. II serait judicieux de proposer un mode de fonction- 
nement reellement generique. 

Pour resoudre ce probleme, il faut modulariser ces comportements au sein d'une entite 
ou d'un groupe d'entites unique afin de beneficier d'un effet de reutilisation maximal. 
C'est ici que l'inversion de controle intervient : plutot que de laisser l'application maitri- 
ser la fabrication des objets dont elle a besoin et la gestion de leurs dependances, un 
framework de creation d'objets doit pouvoir prendre en charge cette problematique de 
maniere generique. 

Le resultat attendu en terme de modelisation serait la disparition pure et simple des fabri- 
ques et de 1' implementation de la notion de singleton dans notre modelisation, comme 
l'illustre la figure 2.6. 

En sous-traitant la gestion des dependances et 1' instanciation des objets, nous rendons le 
modele plus lisible, mais au prix d'une perte d'information puisque la gestion des depen- 
dances n'apparait plus explicitement dans le modele. II faut done veiller a documenter 
correctement les modeles pour pallier cette carence. 

Grace au conteneur leger, nous remplacons des mecanismes specifiques de fabrication 
des objets et de gestion des dependances par un mecanisme generique. En regie gene- 
rale, les conteneurs legers sont parametrables de maniere declarative via des fichiers 
de configuration. Nous definissons ainsi un veritable referentiel des dependances 
entre objets. 
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Si nous reprenons nos quatre criteres d' analyse, nous pouvons constater que la situation 
s'ameliore encore par rapport a l'approche par les modeles de conception : 

• Rigidite. La gestion generique des dependances offre une plus grande souplesse 
dans revolution des interfaces et de leurs implementations. En effet, si le conteneur 
leger est parametre via des fichiers de configuration, la modification de ces derniers 
s'avere moins couteuse que la modification d'une fabrique developpee specif! - 
quement. 

• Fragilite. S ' il n' y a pas ici d' apport majeur, nous pouvons toutefois noter que le conte- 
neur leger fournit une infrastructure eprouvee, qui ajoute un element de confiance dans 
la gestion des dependances, notamment des dependances complexes, comme les 
dependances cycliques, et contribue a isoler plus facilement d'eventuels dysfonction- 
nements applicatifs. 

• Immobilite. Le modele etant simplifie du fait d'une plus grande abstraction apportee 
par le conteneur leger, nous pouvons dire que la reutilisation des concepts est facilitee. 

• Inverifiabilite. Elle est minimisee, car le conteneur leger facilite l'utilisation des simu- 
lacres par rapport a l'approche precedente, qui necessite la reecriture des fabriques. 

Comme nous le voyons, 1' inversion de controle pour la gestion des dependances offre des 
avantages non negligeables en matiere de conception des applications. Cette inversion de 
controle peut etre assuree de deux facons differentes : par la recherche de dependances 
ou par l'injection de dependances, cette derniere etant privilegiee par Spring. 

La section suivante aborde ces deux techniques en les comparant. 

L'injection de dependances 

Les conteneurs legers peuvent etre classes en deux categories en fonction de la facon 
dont ils gerent les dependances entre objets : 

• Les conteneurs legers qui utilisent la recherche de dependances. 

• Les conteneurs legers qui utilisent l'injection de dependances. 

Spring utilise essentiellement l'injection de dependances mais propose aussi la recherche 
de dependances pour des cas specifiques oil l'injection ne fonctionne pas. Nous decrirons 
done les deux modes de fonctionnement. 

L'injection de dependances existe sous trois formes : 

• injection de dependances via le constructeur ; 

• injection de dependances via les modificateurs (setters) ; 

• injection de dependances via une interface. 

Les deux premieres formes sont les plus utilisees et sont proposees toutes deux par 
Spring. Nous n'aborderons done pas la troisieme forme, qui est marginale. 
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Recherche de dependances 

La recherche de dependances consiste pour un objet donne a interroger le conteneur pour 
trouver ses dependances. Ce mode de fonctionnement est typiquement celui propose par 
lesEJB. 

Pour acceder a ces derniers, il est necessaire d'appeler un annuaire JNDI, comme le 
montre le code suivant : 

(...) 

ctx = new InitialContext(proprietes) ; 
ref = ctx. 1 ookupt "MonEJB" ) ; 

home = (MonEJBHome) javax.rmi .PortableRemoteObject.narrowtref , 

MonEJBHome. class); 
monEJB = home.create( ) ; 

Dans notre etude de cas, chaque objet appelle le conteneur leger en lieu et place des 
fabriques specifiques pour recuperer ses dependances. Par exemple, 1' initialisation d'une 
instance de la classe TodoListsManagerlmpl pourrait etre la suivante : 

public class TodoListsManagerlmpl implements TodoListsManager { 
(...) 

TodoListsDAO dao ; 

public TodoListsManagert ) { 
(...) 

dao = (TodoListsDAO)Conteneur.getDependanceC'TodoListsDAO") ; 
(...) 

} 

(...) 

} 

La methode getDependance de notre conteneur fictif instancie la classe Java referencee en 
tant que "TodoListsDAO" dans son referentiel interne. Cette methode etant generique, le 
typage de sa valeur de retour est forcement j a va.lang. Object, ce qui explique la necessite 
du transtypage en TodoListsDAO. Bien entendu, il est suppose ici que la classe associee a 
1'identifiant "TodoListsDAO" implemente bien l'interface TodoListsDAO. II faut noter que le 
respect de cette regie ne pourra malheureusement etre verifie qu'a 1' execution puisque 
notre haut niveau d' abstraction nous fait perdre la securite du typage fort. 

La recherche de dependances contextualisee (Contextualized Dependency Lookup) est 
une autre facon de proceder conforme au principe de 1' inversion de dependances. Elle 
se presente sous la forme d'une interface a implementer par tout objet gere par le contro- 
leur : 

public interface InitDependances { 

public void resoudreDependancestConteneur conteneur) ; 
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Le conteneur leger prenant en charge l'instanciation des objets, il appelle systematiquement 
la methode resoudreDependances juste apres leur creation. 

Dans le cas de notre classe TodoListsManagerlmpl, le code est maintenant le suivant : 

public class TodoListsManagerlmpl implements 
TodoListsManager , Ini tDependances { 
(...) 

TodoListsDAO dao ; 

public TodoListsManager( ) { 
(...) 

} 

public void resoudreDependances(Conteneur conteneur) ( 

dao = (TodoListsDAO)conteneur.getDependanceC'TodoListsDAO"); 

} 

(...) 

} 

La recherche de dependances est une solution simple au probleme de gestion des depen- 
dances. Cependant, elle rend le code explicitement dependant du conteneur leger, et ce 
quel que soit le type de recherche que nous effectuons. Cela presente deux inconvenients 
majeurs : la dependance de l'application vis-a-vis du conteneur leger est plus forte, et les 
tests unitaires sur les objets necessitent la presence systematique du conteneur (du fait 
des appels directs a celui-ci). 

Avec la recherche de dependances, la modelisation representee a la figure 2.6 n'est pas 
atteinte, puisqu'un lien explicite reste present entre les classes et le conteneur qui les 
gere. 



Injection de dependances 

L'injection vise a rendre l'inversion de controle de la gestion des dependances la plus 
transparente possible vis-a-vis des classes concernees. Comme nous l'avons vu a la section 
precedente, la recherche de dependances cree un lien explicite entre les classes et le 
conteneur leger en charge de la gestion de leurs dependances. Grace a l'injection de 
dependances, nous allons pouvoir transformer ce lien explicite en lien implicite. 

Pour proceder a l'injection des dependances, le conteneur leger initialise directement les 
objets (a partir d'un referentiel), liberant ainsi l'application de cette charge. Au lieu 
d'utiliser l'operateur new, le conteneur leger injecte dans l'application les instances dont 
elle a besoin, comme l'illustre la figure 2.7. 

Pour effectuer cette initialisation, le conteneur peut implementer deux methodes : l'injec- 
tion de dependances via le constructeur ou l'injection de dependances via les modificateurs. 
Spring offre la possibilite de combiner l'injection via les constructeurs avec celle fondee 
sur les modificateurs. 
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Injection de dependances via le constructeur 

En Java, toute classe dispose d'un constructeur, qu'il soit explicite, c'est-a-dire imple- 
mente dans le code de la classe, ou par defaut, c'est-a-dire fourni par la machine 
virtuelle. Si nous suivons les bonnes pratiques de programmation orientee objet, le role 
d'un constructeur est de construire une instance d'une certaine classe dans un etat valide. 
Si cet objet possede des dependances (sous forme d'attributs) avec d'autres objets, ces 
dependances sont initialisees par le constructeur. 

Si nous reprenons l'exemple de la classe TodoListsManagerlmpl de l'approche par les 
modeles de conception, nous aurions done le code suivant : 

public class TodoListsManagerlmpl implements TodoListsManager { 
(...) 

TodoListsDAO dao ; 

public TodoListsManagert ) { 
(...) 

dao = TodoLi stsDAOManager .getTodoLi stsDAOt ) ;<- Q 
(...) 

} 

(...) 

} 

Avec la recherche de dependances presentee a la section precedente, nous avons 
remplace une dependance vis-a-vis d'une fabrique specifique par une dependance vis-a- 
vis du conteneur. 



Les fondations de Spring 

Partie I 



L'idee de l'injection de dependances via le constructeur est d'extemaliser l'appel Q afin 
qu'il soit pris en charge par le conteneur leger, charge a celui-ci de transmettre au construc- 
teur 1' instance de la dependance desiree. Le lien explicite avec le conteneur leger est 
remplace par un lien implicite, rendant notre code plus independant du framework dans 
lequel il s' execute. 

Pour arriver a ce resultat, il suffit de transformer le constructeur pour qu'il accepte de 
recevoir en parametres les dependances. Ainsi, notre code se presente de la maniere 
suivante : 

public class TodoListsManagerlmpl implements TodoListsManager { 
(...) 

TodoListsDAO dao ; 

public TodoListsManagerdodoListsDAO pDAO) { 
(...) 

dao = pDAO; 
(...) 

} 

(...) 

} 

Nous avons casse la dependance explicite avec le conteneur. L'instanciation de Todo- 
Li stsManagerlmpl se faisant au sein du conteneur leger, et non par l'operateur new, celui-ci 
emploie le constructeur pour initialiser (injecter) les dependances de l'instance de la 
classe. 

Le principal avantage de l'injection de dependances via le constructeur est que cette tech- 
nique respecte les bonnes pratiques de programmation orientee objet (le constructeur doit 
etre utilise pour creer un objet dans un etat valide). Cependant, son inconvenient majeur, 
en tout cas avec Java, est que les parametres du constructeur sont non pas nommes, mais 
ordonnes. C'est l'ordre des parametres qui permet de savoir quelle dependance est initia- 
lisee. 

Ce mode de fonctionnement s'avere rapidement peu lisible et source d'erreurs des 
qu'augmente le nombre de dependances a gerer pour une classe. Par ailleurs, l'injection 
de dependances via le constructeur pose probleme pour l'heritage. En effet, puisqu'un 
constructeur est specifique de chaque classe et que ses parametres ne sont pas nommes, 
nous perdons la capacite d'heriter de la configuration d'une classe mere a une classe fille 
au niveau du conteneur leger. 

Injection de dependances via les modificateurs 

Outre le constructeur, il est possible d'utiliser les modificateurs (setters) pour initialiser 
les attributs d'un objet. L'injection de dependances via les modificateurs utilise ces 
derniers pour initialiser les dependances d'un objet. Bien entendu, cela suppose que la 
classe dispose des modificateurs permettant de le faire. 
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Si nous reprenons notre classe TodoUstsManagerlmpl, nous obtenons le code suivant : 

public class TodoListsManagerlmpl implements TodoListsManager { 
(...) 

TodoListsDAO dao ; 

public TodoListsManagert ) { 

(...) 

} 

public void setDaododoListsDAO pDAO) { 
dao = pDAO ; 

} 

(...) 

} 

Le conteneur leger utilise la methode setDao pour initialiser la dependance de TodoListsMa- 
nagerlmpl vis-a-vis de TodoLi stsDAO au lieu d'utiliser le constructeur comme precedemment. 

II faut noter qu'un modificateur n'est pas forcement associe a un seul attribut de la classe 
et qu'il peut effectuer des traitements complexes pour initialiser l'objet. 

Le principal avantage de cette forme d' injection est que les modificateurs sont nommes, 
puisqu'il s'agit de methodes. Les noms apparaitront de la sorte explicitement dans le 
parametrage du conteneur leger, contrairement a 1' injection via le constructeur, oil seul 
l'ordre apparait. En contrepartie, cette facon de proceder constitue une entorse a la bonne 
pratique consistant a utiliser le constructeur pour initialiser une instance d'objet. Nous ne 
beneficions plus de la securite offerte par le constructeur, dont les parametres indiquent 
explicitement toutes les dependances a initialiser. 

Malgre ce defaut, l'injection via les modificateurs est generalement preferee du fait de sa 
meilleure lisibilite, facilitant la maintenance des dependances. De plus, cette methode 
permet a une classe fille d'heriter de la configuration de sa classe mere au niveau du 
conteneur leger. 



Gestion du cycle de vie des objets 

Comme nous venons de le voir, 1' inversion de controle dans la gestion des dependan- 
ces implique une mainmise du conteneur leger lors de 1' initialisation des objets. Ce 
controle permet par extension au conteneur d' assurer la gestion du cycle de vie des 
objets. 

Cette gestion du cycle de vie des objets comporte generalement pour les conteneurs 
legers deux volets : 

• la gestion des singletons ; 

• la generation d'evenements indiquant le changement d'etat de l'objet. 



I Les fondations de Spring 
I Partie I 

Gestion des singletons 

Classiquement, le design pattern singleton est implements dans chaque classe ne devant 
avoir qu'une seule instance au sein de 1' application. Un singleton est souvent implements 
de la maniere suivante : 

public class TodoListsManagerlmpl implements TodoListsManager { 

(...) 

private static TodoListsManagerlmpl instance = 
new TodoListsManagerlmpl () ; 

publ ic TodoListsManagerlmpl getlnstance( ) { 
return instance; 

} 

pri vate TodoLi stsManagerlmpl ( ) ( 
(...) 

} 

} 

Le constructeur a une portee privee afin d'eviter que des instances de la classe puissent 
etre creees en dehors de celle-ci par des appels a l'operateur new. Seule la methode 
getlnstance peut etre utilisee pour recuperer l'instance unique de la classe. 

Cette implementation du design pattern singleton a beau etre tres generique, elle est 
malheureusement dependante de la classe a instancier, empechant toute reutilisation. Par 
ailleurs, il n'existe pas de norme de codage de ce design pattern. Ainsi, il est possible de 
trouver au sein d'une meme application plusieurs implementations differentes, utilisant 
des noms de methodes differents, etc. 

Puisque le conteneur leger assure l'instanciation des objets, il est en mesure de controler 
le nombre d' instances creees et de solutionner ainsi le probleme de la duplication de la 
mecanique du singleton au sein des classes devant implementer ce design pattern. 

II suffit de declarer une classe comme etant un singleton aupres du conteneur leger pour 
que celui-ci ne genere qu'une instance unique. II n'est de la sorte plus necessaire 
d'implementer la mecanique du singleton au sein de chaque classe devant implementer 
ce design pattern. En contrepartie, un transtypage est necessaire. 

Generation d'evenements 

Au sein des conteneurs legers, le cycle de vie des objets est souvent reduit a sa plus 
simple expression, a savoir la vie puis la mort. Le cycle de vie qu'ils proposent est done 
des plus simples en comparaison de celui des EJB - il n'y a pas, par exemple, de notion 
d' activation ou de deactivation - mais repond neanmoins aux besoins des objets qu'ils 
manipulent. 

La generation d'evenements consiste a appeler des methodes specifiques de l'objet en 
fonction de ses changements d'etats. Ces methodes specifiques peuvent etre formalisees 
sous forme d'interfaces a implementer ou specifiees par parametrage du conteneur leger. 



Les concepts des conteneurs legers 



Chapitre 2 



Nous aurons ainsi une methode qui sera appelee par le conteneur leger apres 1' instantia- 
tion de l'objet permettant, par exemple, d'effectuer des controles de coherence sur l'etat 
de l'objet. Une autre methode sera appelee par le conteneur leger juste avant la destruc- 
tion de l'objet. Ce type de methode est souvent utile pour effectuer des operations de 
nettoyage ou de liberation de ressources. 



Conclusion 

Ce chapitre s'est efforce de comparer plusieurs approches permettant de concevoir une 
version simplifiee du modele metier de Tudu Lists. Les approches naive et technologique 
se sont averees peu satisfaisantes car trop rigides, fragiles, immobiles et inverifiables. 

La situation s'est nettement amelioree avec l'approche par les modeles de conception, 
meme si cette derniere souffre de certaines faiblesses, notamment une plus grande 
complexite du modele du fait de 1' utilisation dans certains cas de singletons et de fabriques. 
Chacun de ces cas a necessite une implementation specifique de ces modeles. 

Grace a l'injection de dependances et a la gestion du cycle de vie des objets, les conte- 
neurs legers permettent d'atteindre la modelisation ideale illustree a la figure 2.6, qui 
offre un resultat nettement ameliore selon nos criteres d' analyse (rigidite, fragilite, 
immobilite et inverifiabilite). Les modeles de conception sont implemented directement 
au sein du conteneur leger, liberant ainsi 1' application de leur implementation specifique. 

Cependant, il est important de garder a l'esprit que l'injection de dependances n'est pas 
la pierre philosophale de la programmation. L'injection de dependances est un outil 
permettant de rendre une modelisation plus flexible. Comme nous l'avons vu, cette flexi- 
bilite a un cout. II faut done s' assurer systematiquement que la rlexibilite du modele est 
justifiee. Par exemple, des abstractions fondamentales comme les classes Todo et TodoLi st 
n'ont nullement besoin de flexibilite puisqu'elles representent les invariants de notre 
application. 

Maintenant que nous avons explicite les principes de fonctionnement des conteneurs 
legers, nous pouvons aborder le fonctionnement de Spring. 
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Le chapitre precedent a detaille les principes de fonctionnement des conteneurs legers et 
montre qu'ils amelioraient de maniere significative la qualite d'une application. C'est a 
partir de ces bases conceptuelles que nous abordons ici le conteneur leger de Spring. 

Spring propose une multitude de facons d'utiliser son conteneur leger, ce qui est souvent 
deroutant pour le developpeur decouvrant cet outil. Ann de permettre au lecteur d'utiliser 
efficacement le framework, nous nous concentrons dans le present chapitre sur les fonc- 
tionnalites utilisees par la grande majorite des projets. 

Dans un premier temps, nous abordons la notion de fabrique de Beans (les Beans sont les 
objets geres par le conteneur leger selon la terminologie Spring) et de contexte d' applica- 
tion (application context), qui permettent de configurer et dialoguer avec le conteneur 
leger. 

Nous decrivons ensuite les differentes techniques dont nous disposons pour definir nos 
objets, ainsi que leurs dependances au sein du conteneur leger. Nous detaillons en outre 
le cycle de vie des objets et les differentes interfaces disponibles pour leur permettre de 
communiquer avec le conteneur leger. 

En fin de chapitre, nous evoquons diverses fonctionnalites avancees du conteneur, 
souvent utilisees dans les projets. 

Fabrique de Bean et contexte d'application 

La fabrique de Bean (Bean Factory) est l'interface de base permettant aux applications 
reposant sur le conteneur leger de Spring d'acceder a ce dernier. Elle definit les fonction- 
nalites minimales dont dispose 1' application pour dialoguer avec le conteneur. 



Les fondations de Spring 

Partie I 



Cette interface comporte plusieurs implementations pretes a l'emploi. Spring etant un 
framework ouvert (du fait du decouplage systematique entre interfaces et implementa- 
tions), il est possible de definir notre propre implementation pour repondre a des besoins 
specifiques, non couverts par les implementations proposees par Spring. 

Le contexte d'application (application context) est une interface qui etend la notion de 
fabrique de Bean en ajoutant des fonctionnalites supplementaires tres utiles pour les 
applications. La majorite des projets fondes sur Spring utilisent des implementations de 
cette interface plutot que des implementations directes de la fabrique de Bean, conformement 
aux recommandations de la documentation de Spring. 



La fabrique de Bean 

La notion de fabrique de Bean, qui offre un moyen d'acces au conteneur leger, est mani- 
pulable par 1' application au travers de deux interfaces complementaires : 1' interface 
BeanFactory, qui definit l'acces aux Beans geres par le conteneur, et l'interface BeanDef i - 
nitionRegistry, qui formalise la definition des Beans que le conteneur leger doit gerer. 

Ces interfaces disposent de plusieurs implementations fournies en standard par Spring, 
mais elles peuvent aussi etre implementees specifiquement dans le cadre d'un projet. 

L'interface BeanFactory 

L'interface BeanFactory permet au reste de l'application d'acceder aux objets geres par le 
conteneur leger. 

Cette interface est tres succincte, comme le montre son code, reproduit partiellement ci- 
dessous : 

package org. springframework. beans. factory; 
(...) 

public interface BeanFactory { 
(...) 

Object getBeantString name) throws BeansException; 
Object getBeantString name. Class requi redType) 

throws BeansException; 
boolean containsBean(String name); 
boolean isSingleton(String name) 

throws NoSuchBeanDef ini ti on Except ion ; 
Class getType(String name) throws NoSuchBeanDefinitionException; 
String[] getAliases(String name) 

throws NoSuchBeanDefinitionException ; 

} 

Les methodes proposees par cette interface permettent uniquement d'interroger le conte- 
neur leger a propos des objets dont il a la charge. Les objets sont designes par un nom 
sous forme de chaine de caracteres (par exemple, le parametre id permettant de definir 
ridentifiant unique du Bean). 
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La methode containsBean verifie pour un nom donne qu'un objet correspondant est bien 
gere dans le conteneur leger. 

Les methodes getBean permettent de recuperer l'instance d'un objet a partir de son nom. 
L'une d'elle prend un parametre supplementaire, requi redType, afin de contraindre le type 
d'objet renvoye par getBean pour plus de securite. Si le nom fourni ne correspond pas a un 
objet dont le type est celui attendu, une exception est generee. Par ailleurs, la methode 
getType permet de connaitre le type d'un objet a partir de son nom. 

Un Bean renvoye par la fabrique peut etre un singleton ou non. Nous parlons dans ce 
dernier cas de prototype dans la terminologie Spring. La methode isSingleton permet de 
savoir, a partir du nom d'un objet, s'il s'agit ou non d'un singleton. 

Tout objet dans Spring peut avoir des noms multiples, ou alias. La methode getAlias 
fournit l'ensemble des alias associes a un objet dont nous connaissons le nom. 

L'interface BeanFactory est etendue par d'autres interfaces definissant des fonctionnalites 
supplementaires. Citons notamment l'interface ConfigurableBeanFactory, qui definit le 
protocole pour configurer le conteneur leger, l'interface ListableBeanFactory, qui fournit 
des fonctions avancees pour consulter les objets geres par le conteneur ou encore l'inter- 
face Hierarchical BeanFactory, qui permet de definir une hierarchie de fabriques de Bean. 

L i nterface BeanDefinitionRegistry 

Si toutes ces fonctions sont necessaires pour l'utilisation du conteneur leger, elles ne sont 
cependant pas suffisantes pour le faire fonctionner. Notons notamment 1' absence totale de 
fonctions permettant d'indiquer au conteneur leger les objets qu'il gere et leurs dependances. 

Ces fonctions sont formalisees par l'interface BeanDefinitionRegistry, qui specifie le 
protocole pour definir les objets a gerer par le conteneur ainsi que leurs dependances. 

Ce protocole est reduit au strict necessaire, comme le montre son code, reproduit partiel- 
lement ci-dessous : 

package org. spring-framework. beans. factory. support; 
(...) 

public interface BeanDefinitionRegistry { 
(...) 

int getBeanDefinitionCount( ) ; 

String[] getBeanDefinitionNamest ) ; 

boolean containsBeanDefinition(String beanName); 

BeanDefinition getBeanDefinition(String beanName) 

throws NoSuchBeanDef initionException; 
void registerBeanDefinitiontString beanName, BeanDefinition 

beanDefinition) 

throws BeansException; 
void registerAlias(String beanName, String alias) 
throws BeansException; 

} 
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L' operation d'enregistrement d'un objet s'effectue par le biais de la methode register- 
BeanDefinition, qui prend en parametres le nom de l'objet et sa definition. Cette derniere 
est formalisee par l'interface BeanDef inition, qui fournit au conteneur les informations 
necessaires pour gerer l'objet et ses proprietes. 

La methode registerAl ias permet pour sa part d'enregistrer les differents noms qu'un 
objet possede au sein du conteneur leger. Les autres fonctions sont destinees a la consul- 
tation des definitions des objets qui sont geres par le conteneur. 

Implementations de BeanFactory et BeanDef initionRegistry 

Grace aux interfaces BeanFactory et BeanDef initionRegistry, les concepteurs de Spring ont 
formalise les differentes manieres de faire dialoguer 1' application avec le conteneur leger. 

A partir de cette formalisation sous forme d'interfaces, plusieurs implementations sont 
possibles, permettant de choisir celle qui est la mieux adaptee. Spring fournit plusieurs 
implementations directement utilisables, qui suffisent dans la grande majorite des cas. 
Bien entendu, nous avons toujours la possibility de developper notre propre implementation, 
mais nous n'aborderons pas ce genre de besoin dans le contexte de cet ouvrage. 

Une des implementations les plus simples mises a la disposition des applications est la 
classe DefaultListableBeanFactory. Situee, comme les autres implementations fournies 
par Spring, dans le package org. spring-framework. beans. factory. support, cette classe 
fournit un acces simple (via les interfaces BeanFactory et BeanDefinitionRegistry) au 
conteneur leger mais sans valeur ajoutee. 

La definition des objets a gerer pour une application donnee doit done etre developpee 
specifiquement. Nous pouvons utiliser pour cela un fichier de proprietes, qui sera lu par 
P application pour declarer chaque objet a gerer aupres du conteneur leger via la methode 
register BeanDef inition de l'interface BeanDef initi on Reg i stry. 

DefaultListableBeanFactory fournit le minimum de fonctionnalites necessaires et peut 
servir de base pour developper nos propres implementations. Dans la majorite des cas, 
les implementations plus evoluees fournies par Spring sont toutefois preferables a cette 
classe. 

L' implementation Xml BeanFactory supporte la definition des objets sous forme de fichiers 
XML. Spring dispose en effet d'un langage XML de definition d'objets formalise par des 
schemas XML. Precedemment, dans les versions 1.x de Spring, il s'agissait d'une DTD 
beaucoup moins satisfaisante en terme de verification du respect du langage. 

Le schema est consultable a PURL http://www.springframework.org/schema/beans. Le langage 
specifie par ce schema est identique a celui de Pancienne DTD. Les fichiers de configu- 
ration fondes sur la version 1.2 de Spring n'ont de la sorte pas a etre modifies pour fonc- 
tionner avec la version 2.0. La definition des objets sous forme XML est celle qui est la 
plus utilisee dans les projets utilisant Spring. Dans la suite de cet ouvrage, nous nous 
concentrons done sur cette forme. 

Pour aller plus loin en matiere de fonctionnalites, Spring definit la notion de contexte 
d' application, qui englobe les services du conteneur leger de finis precedemment et ajoute 
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des services additionnels, utiles aux applications mais sans rapport direct avec la notion 
de conteneur leger. 



Le contexte d 'application 

La notion de contexte d' application etend celle de fabrique et de registre de Bean en 
ajoutant de nouvelles fonctionnalites tres utiles pour les applications, notamment les 
suivantes : 

• Support des messages et de leur internationalisation. 

• Support avance du chargement de fichiers (appeles ressources), que ce soit dans le 
systeme de fichiers ou dans le classpath de 1' application. 

• Support de la publication d'evenements permettant a des objets de 1' application de 
reagir en fonction d'eux. 

• Possibility de definir une hierarchie de contextes. Cette fonctionnalite est tres utile 
pour isoler les differentes couches de 1' application (les Beans de la couche presenta- 
tion ne sont pas visibles de la couche service, par exemple). Cette possibilite est 
evoquee dans la partie II de l'ouvrage. 

Ces fonctionnalites additionnelles seront presentees plus en detail en fin de chapitre, car 
elles ne concernent pas a proprement parler le conteneur leger. 

L' interface Appl icationContext dispose, comme les precedentes, de plusieurs implemen- 
tations, permettant de choisir celle qui correspond le mieux aux besoins de 1' application. 
Elle dispose ainsi de deux implementations equivalentes a Xml BeanFactory : FileSys- 
temXml Appl icationContext, pour lire les fichiers de configuration dans le systeme de 
fichiers, et CI assPathXml Appl icationContext, pour les lire dans le classpath. 

Le code ci-dessous montre comment utiliser un contexte d' application dans une application 
Java executable en ligne de commande : 

public static void main(String[] args) throws IOException { 
Appl icationContext context = new 

Fi 1 eSystemXml Appl i cati onContext ( "appl i cati onContext . xml " ) ; 
UnBean monBean = (UnBean) context. getBean( "monBean" ) ; 
(...) 

} 

Nous commencons par initialiser un contexte d' application avec les objets definis dans le 
fichier applicationContext.xml, stocke dans le repertoire courant de 1' application. Nous 
interrogeons ensuite le conteneur leger via la methode getBean pour recuperer une 
instance de la classe UnBean. 

Par convention, les noms des fichiers de definition des objets s'appellent application- 
Context.xml. Si la definition des objets de l'application est separee en plusieurs fichiers, 
une pratique recommandee des lors que l'application manipule un grand nombre 
d'objets, les noms des fichiers sont prefixes par applicationContext- et conservent 
l'extension .xml. Bien entendu, le respect de cette norme n'est pas obligatoire. 
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Pour notre application exemple Tudu Lists, les fichiers suivants sont crees dans le reper- 
toire WEB-INF : 

• applicationContext.xml : contient la definition des services de Tudu Lists. 

• applicationContext-hibernate.xml : contient la definition des DAO. 

• appplicationContext-security.xml : contient la definition des objets gerant la securite 
de l'application. 

• applicationContext-dwr.xml : contient la definition des objets utilises par le 
framework AJAX DWR. 

• action-servlet.xml : contient la definition des actions Struts. 

Dans le cadre de ce chapitre, nous nous interessons essentiellement au premier et au 
deuxieme fichier de configuration. Le contenu des autres sera precise au fil de l'ouvrage. 

En plus de FileSystemXmlAppl icationContext et CI asspathXml Appl icati onContext, d'autres 
implementations sont disponibles specifiquement pour les applications Web, comme 
Xml WebAppl icati onContext, mais celles-ci sont abordees dans la partie II. 

Notons que, dans le cas des applications Web utilisant Struts ou Spring MVC, la defini- 
tion du contexte d' application s'effectue via le fichier de configuration standard 
web.xml. II n'est done pas necessaire de le creer de maniere programmatique, comme 
dans 1' exemple precedent. 

Par ailleurs, les objets de l'application developpes pour ces frameworks, comme les 
actions Struts, n'ont pas besoin d'utiliser la methode getBean. Ces objets etant eux- 
memes geres par le conteneur, lequel est execute au lancement de l'application Web, 
P injection de leurs dependances se fait automatiquement. 

En resume 

La notion de fabrique de Bean formalise l'acces aux objets geres par le conteneur leger. 
La definition des objets geres est formalisee pour sa part par la notion de registre de 
Bean. 

Ces deux notions constituent le minimum requis pour utiliser le conteneur leger de 
Spring dans une application. Le contexte d' application etend ces deux notions en fournis- 
sant non seulement Pensemble des services definis precedemment mais aussi des fonc- 
tionnalites supplementaires utiles aux applications (comme l'internationalisation ou 
l'acces generique aux ressources). 

La majorite des projets utilisant Spring utilisent ainsi la notion de contexte d' application 
dans une de ses implementations. Dans tous les cas, la definition des objets a gerer se 
realise de maniere privilegiee sous forme XML a partir d'un langage formalise par 
Spring sous forme de schema. 



Les sections suivantes se penchent sur la facon d'utiliser ce langage. 
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Definition d'un Bean 

Dans Spring, la notion de Bean correspond a celle d'instance de classe. Cette classe peut 
etre un JavaBean, mais ce n'est pas obligatoire, et il peut s'agir aussi d'une classe quel- 
conque. L'essentiel est de fournir un constructeur ou un ensemble de modificateurs pour 
permettre a Spring d'initialiser l'objet correctement. II est aussi possible d'utiliser des 
fabriques specifiques pour les instanciations complexes, comme nous le verrons un peu 
plus loin avec les techniques avancees. 

La definition d'un Bean peut s'effectuer de maniere programmatique, via la methode 
registerBeanDefinition de l'interface BeanDefinitionRegistry, mais il est nettement plus 
commode la plupart du temps d'externaliser cette definition dans un fichier de configuration 
XML. Dans cette section, nous nous concentrons sur cette derniere facon. 



Les informations de base 

La definition d'un Bean necessite au minimum la fourniture de son type (sa classe) et de 
son nom. II est aussi necessaire de savoir si le Bean en question est un singleton ou non. 

Nous allons voir comme indiquer au conteneur leger ces informations primordiales. 
Structure du fichier de configuration 

La definition des Beans s'effectue dans un fichier XML utilisant les schemas specifies par 
Spring. Lensemble des definitions est encadre par le tag beans. C'est dans ce tag que sont 
specifies les differents schemas necessaires. Ici, nous n'en utilisons qu'un, mais nous verrons 
qu'il existe deux autres schemas, un pour la POA et un autre pour la gestion des transactions. 

Voici une illustration de l'utilisation de ce tag beans dans le fichier applicationContext.xml 
du projet Tudu Lists : 

<?xml version="1.0" encoding="UTF-8"?> 



<beans xmlns="http: //www. springframework.org/schema/beans" 

xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" 
xmlns:aop=" http://www.spr ingframework.org/schema/aop" 
xmlns :tx="http: //www. springframework.org/schema/tx" 

xsi :schemaLocation=" 

http://www.springframework.org/schema/beans 

http: //www. springf ramework.org/schema/beans/spring-beans .xsd 
http://www.springframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop.xsd 
http: //www. springf ramework.org/schema/tx 
http://www.springframework.org/schema/tx/spring-tx.xsd"> 



(...)<!-- definitions des beans --> 



</beans> 
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Les fichiers de configuration des contextes d' application utilisent plusieurs espaces de 
nommage, avec chacun un schema specifique. L'espace de nommage par defaut est celui 
de la definition des Beans (premiere ligne en gras dans le code). Les espaces de 
nommage aop et tx concernent respectivement la POA et la gestion des transactions. 
Nous aurons l'occasion d'y revenir dans le cours des chapitres suivants. 

La localisation des schemas est specifiee par le parametre xsi :schemal_ocation. Ainsi, le 
schema par defaut http://www.springframework.org/schema/beans se situe a l'URL http://www.spring- 
framework.org/schema/beans/spring-beans.xsd (deuxieme et troisieme lignes en gras). 

Nommage des Beans 

Une fois cette structure mise en place, nous pouvons definir nos Beans. 

Nous utilisons pour cela le tag bean (a ne pas confondre avec le tag beans qui le contient) 
et fournissons au minimum deux informations : la classe et le nom du Bean. 

Pour definir le Bean nomme userManager, de type tudu. service. impl .UserManagerlmpl, 
nous pouvons ecrire : 

<bean id="userManager" class="tudu. service. impl .UserManagerlmpl "/> 

Le resultat de cette configuration est une instance userManager, dont les proprietes ne 
sont pas initialisers, car elles necessitent une configuration specifique, que nous 
detaillons plus loin dans ce chapitre. Le parametre id specifie l'identifiant unique (le 
nom) du Bean. 

II peut etre utile de definir des alias. II suffit pour cela d'utiliser le parametre name, qui 
accepte plusieurs noms separes par des virgules ou des espaces. 

Dans notre exemple, nous pouvons definir les alias suivants : 

<bean id="userManager" class="tudu. service. impl .UserManagerlmpl " 
name="userManagerService,gestionUtil isateurs"/> 

Selection du mode d'instanciation 

Par defaut, Spring considere que les Beans sont des singletons. Si nous appelons 
plusieurs fois la methode getBean du contexte d' application, nous obtenons done toujours 
le me me objet. 

Ce mode de fonctionnement est reglable via le parametre singleton. Comme explique 
precedemment, dans la terminologie de Spring, les Beans qui ne sont pas des singletons 
sont appeles des prototypes. Si nous voulons signaler explicitement que userManager est 
un singleton, il nous suffit de completer notre code de la facon suivante : 

<bean id="userManager" cl ass="tudu. service. impl .UserManagerlmpl " 
singleton="true"/> 

Pour le transformer en prototype, il suffit de remplacer la valeur true par f al se. 
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Les methodes d'injection 

Nous avons vu a la section precedente que, grace a Spring, les applications n'ont plus a 
se preoccuper d'implementer le design pattern fabrique, puisqu'il est fourni directement 
par le framework. 

Cependant, l'essentiel de la puissance de Spring reside dans 1' injection de dependances, 
c'est-a-dire dans 1' initialisation des proprietes d'un Bean, qu'elles soient simples (entier, 
reel, chaine de caracteres, etc.) ou qu'elles fassent reference a d'autres Beans geres par le 
conteneur (nous parlons alors de collaborateurs). 

Pour initialiser les proprietes d'un Bean, Spring propose deux methodes d'injection : soit 
en utilisant les modificateurs du Bean, s'il en a, soit en utilisant un de ses constructeurs. 
Dans la plupart des cas, l'injection par modificateur est preferee a l'injection par construe - 
teur, car elle presente l'avantage de fournir explicitement le nom de chacune des proprietes 
initialisees, ce qui n'est pas le cas avec un constructeur, puisque, en Java, les parametres 
ne sont pas nommes. 

L'injection par modificateur s'avere par ailleurs plus pratique pour l'heritage de configu- 
ration, que nous abordons en fin de chapitre. Par contre, l'utilisation de l'injection par 
constructeur est plus securisante, puisqu'elle assure que l'objet est correctement initialise 
(en supposant que le constructeur soit correct). II est toutefois possible de combiner les 
deux types d'injections au sein d'une meme application. 

L'injection par modificateur 

L'injection par modificateur se parametre au sein d'une definition de Bean en utili- 
sant le tag property. Ce tag possede un parametre name specifiant le nom de la 
propriete a initialiser. Rappelons qu'un modificateur ne correspond pas forcement a 
un attribut de l'objet a initialiser et qu'il peut s'agir d'un traitement d'initialisation 
plus complexe. 

Le tag property s'utilise en combinaison avec le tag val ue, qui sert a specifier la valeur a 
affecter a la propriete lorsqu'il s'agit d'une propriete canonique, ou avec le tag ref, s'il 
s'agit d'un collaborateur. 

Dans le fichier applicationContext-hibernate.xml, nous initialisons la propriete canonique 
configLocation du Bean sessionFactory de la maniere suivante : 

<bean id="sessionFactory" 

class="org.springf ramework.orm.hibernate3. Local Sess ion Factory Bean "> 

<property name="conf igLocation"> 

<value>cl asspath:hibernate.cfg.xml</valiie> 
</property> 



</bean> 
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II est possible d' avoir une ecriture plus concise de cette configuration en utilisant le para- 
metre val ue du tag property en lieu et place du tag de meme nom : 

<bean id="sessionFactory" 

class="org.springf ramework.orm.hibernate3. Local Session Factory Bean "> 

<property name="configLocation" 

val ue=" class path: hi bernate.cfg.xml "/> 

</bean> 

Linjection par constructeur 

L'injection par constructeur se parametre au sein d'une definition de Bean en specifiant 
les parametres du constructeur par le biais du tag constructor-arg. 

Supposons que nous ayons une classe UnBean codee de la maniere suivante : 

public class UnBean ( 
private String chaine; 
private int entier; 

public UnBean(String chaine, int entier) { 
this. chaine = chaine; 
this. entier = entier; 

} 

(...) 

La configuration de ce Bean s'effectue ainsi : 

<bean id="monBean" cl ass="UnBean"> 
<constructor-arg> 

<val ue>val eur</val ue> 
</constructor-arg> 
<constructor-arg> 

<value>10</value> 
</constructor-arg> 
</bean> 

II est possible de changer l'ordre de definition des parametres du constructeur en utilisant 
le parametre index du tag constructor-arg. L' indexation se fait a partir de 0. 

La configuration suivante est equivalente a la precedente, bien que nous ayons inverse 
l'ordre de definition des parametres du constructeur : 

<bean id="monBean" cl ass="UnBean"> 
<constructor-arg index="l"> 

<value>10</value> 
</constructor-arg> 
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<constructor-arg index="0"> 

<val ue>val eur</val ue> 
</constructor-arg> 
</bean> 

Dans certains cas, il peut y avoir ambiguite dans la definition du constructeur, empechant 
Spring de choisir correctement ce dernier. Pour illustrer ce probleme, ajoutons les deux 
constructeurs a la classe UnBean : 

public UnBeantString chaine) { 
this.chaine = chaine; 
this.entier = 0; 

} 

public UnBean(int entier) { 
this.chaine = "" ; 
this.entier = entier; 

} 

Si nous ecrivons la definition de Bean suivante, une ambiguite apparait, puisque les deux 
constructeurs peuvent etre utilises a partir de ce parametrage : 

<bean id="monBean" cl ass="UnBean"> 

<constructor-arg> 
<value>10</value> 

</constructor-arg> 
</bean> 

Par defaut, Spring selectionne le premier constructeur supportant cette configuration, en 
l'occurrence celui qui initialise l'attribut chaine. Pour lever l'ambigui'te, il est possible 
d'utiliser le parametre type du tag constructor-arg : 

<bean id="monBean" class="tudu.llnBean"> 

<constructor-arg type="int"> 
<value>10</value> 

</constructor-arg> 
</bean> 

Grace a ce parametre, nous selectionnons le constructeur qui initialise enti er. Pour selec- 
tionner 1' autre constructeur explicitement, nous pouvons ecrire : 

<bean id="monBean" class="tudu.UnBean"> 
<constructor-arg type="java.l ang.String"> 

<value>10</value> 
</constructor-arg> 
</bean> 

Lorsque le type de 1' argument est une classe, il est necessaire de le qualifier complete - 
ment (c'est-a-dire en precisant son package), comme nous pouvons le constater pour le 
type String. 
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Comme pour l'injection par modificateur, le tag constructor-arg dispose d'une forme 
plus concise, ne necessitant pas l'utilisation du tag value. Si nous reprenons notre 
derniere configuration, nous pouvons l'ecrire de la maniere suivante : 

<bean id="monBean" cl ass="UnBean"> 

<constructor-arg type="java.lang. String" value="10"/> 

</bean> 

Injection des proprietes 

Les exemples fournis a la section precedente nous ont permis de nous familiariser avec la 
configuration des proprietes d'un Bean. Nous allons maintenant voir plus en detail quelles 
sont les possibilites de Spring en la matiere. 

L'injection des proprietes est le mecanisme fondamental du conteneur leger. Nous allons 
voir dans cette section comment sont gerees les valeurs simples et les structures de 
donnees. 

Injection de valeurs simples 

Spring supporte l'injection de valeurs simples en convertissant les chaines de caracteres 
fournies au tag ou au parametre val ue dans le type de la propriete a initialiser. 

Outre les chaines de caracteres et les nombres, les types de proprietes supportes par 
Spring sont les suivants : 

• Booleens. 

• Type char et java.lang. Character. 

• Type java.util .Properties. 

• Type java.util .Locale. 

• Type java.net. URL. 

• Type java.io. File. 

• Type java.lang. Class. 

• Tableaux de bytes (la chaine de caracteres est transformee via la methode getBytes de 
String). 

• Tableaux de chaines de caracteres (chaque chaine doit etre separee par une virgule 
selon le format CSV). 

Afin d'illustrer l'utilisation de ces differentes valeurs, modifions notre classe UnBean en 
consequence : 

public class UnBean { 
private String chaine; 
private int entier; 
private float reel ; 
private boolean booleen; 
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private char caractere; 

private java.util .Properties proprietes; 

private java.util .Locale localisation; 

private java.net. URL url; 

private java.io.File fichier; 

private java.lang. Class classe; 

private byte[] tab2bytes; 

private String[] tab2chaines; 

// definition des accesseurs et modificateurs de chaque attribut 
(...) 

} 

Si nous utilisons l'injection par modificateur, plus explicite, la definition du Bean est la 
suivante : 

<bean id="monBean" cl ass="UnBean"> 

<property name="chaine" val ue="val eur"/> 

<property name="entier" value="10"/> 

<property name="reel" value="10.5"/> 

<property name="bool een" val ue="true"/> 

<property name="caractere" value="a"/> 

<property name="proprietes" 
val ue="log4j. root Logger=DEBUG,C0NS0LE\nlog4j.logger.tudu=WARN"/> 

<property name="localisation" val ue="f r_FR"/> 

<property name="url" value="http://tudu.sf .net"/> 

<property name="fichier" value="file:c:\\temp\\test.txt"/> 

<property name="cl asse" value="java.lang.String"/> 

<property name="tab2bytes" val ue="val eur"/> 

<property name="tab2chaines" value="valeurl,valeur2"/> 
</bean> 

Pour les attributs propri etes et 1 ocal i sati on, le format de la chaine de caracteres respecte 
le format attendu pour ces types de donnees (ce format est specifie dans l'API J2SE). 
C'est notamment la raison pour laquelle \n figure dans 1' initialisation de proprietes, car 
son format impose la definition d'une propriete par ligne. 

Pour la propriete fichier, le format utilise est celui des URL. Ce format supporte le 
protocole cl asspath introduit par Spring pour acceder aux fichiers se trouvant dans le class- 
path (voir en fin de chapitre V abstraction des acces aux ressources). 

Si Spring supporte les types les plus utilises, pour des besoins specifiques, il peut etre 
necessaire de supporter de nouveaux types. Nous etudions cette possibilite a la section 
dediee aux techniques d' injection avancees. 

Injection de la valeur null 

Dans certaines situations, il est necessaire d'initialiser explicitement une propriete a nul 1 . 
Pour cela, Spring propose le tag nul 1 . 
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La configuration suivante initialise attrl de UnBean a nul 1 en utilisant le tag nul 1 en lieu et 
place du tag val ue : 

<bean id="monBean" class="tudu.UnBean"> 

<constructor-arg type=" java . 1 ang.String"> 
<null/> 

</constructor-arg> 
</bean> 

Bien entendu, le tag nul 1 est utilisable quelle que soit la methode d'injection. 
Injection de structures de donnees 

Outre les valeurs simples, Spring supporte l'injection de structures de donnees. Ces 
dernieres peuvent stacker soit des ensembles de valeurs simples (tag value), soit des 
objets geres par le conteneur (tag ref), dont nous verrons la definition un peu plus loin. 

Les structures de donnees supportees sont java.util .Map, java.util .Set et java.util .List. 
Leur initialisation utilise des tags specifiques. 

Outre ces trois types, Spring fournit des tags specifiques pour initialiser les proprietes du 
type java.util .Properties. Ces tags sont plus lisibles que la configuration que nous avons 
utilisee precedemment. Notons que, contrairement aux structures de donnees preceden- 
tes, la classe Properties n'accepte que les chaines de caracteres, puisqu'il s'agit du seul 
type qu'elle est capable de manipuler. 

Le type java.util. Map 

L' interface java . uti 1 .Map represente un objet qui fait correspondre des cles a des valeurs. 
Une Map ne peut contenir de cles dupliquees (elles sont uniques), et une cle ne peut 
correspondre qu'a une seule valeur. 

L' initialisation d'une propriete ayant ce type s'effectue grace aux tags map et entry, a utiliser 
en combinaison avec le tag property. 

Si nous ajoutons un attribut map de type java.util .Map a notre Bean UnBean, nous pouvons 
ajouter la ligne suivante dans notre configuration pour l'initialiser : 

<property name="map"> 
<map> 

<entry key="clel"> 

<val ue>valeurl</val ue> 
</entry> 

<entry key="cle2"> 

<val ue>valeur2</val ue> 
</entry> 
</map> 
</property> 

Le tag map encadre la definition du contenu de la propriete, et le tag entry specifie un 
couple cle -valeur contenu dans la propriete. 



Le conteneur leger de Spring 



Chapitre 3 



II est possible de se passer de l'utilisation du tag val ue en utilisant le parametre de meme 
nom dans le tag entry : 

<entry key="clel" val ue="val eurl"/> 
<entry key="cle2" val ue="val eur2"/> 

Le type java.util.Set 

L'interface j ava . ut1 1 . Set est une collection d'elements qui ne contient aucun dupliqua et 
au maximum une fois la valeur null. Ce type correspond a la notion mathematique 
d' ensemble. 

L' initialisation d'une propriete ayant ce type s'effectue grace au tag set, a utiliser en 
combinaison avec le tag property. 

Si nous ajoutons un attribut set de type java.util .Set a notre Bean UnBean, nous devons 
ajouter la ligne suivante dans notre configuration : 

<property name="set"> 
<set> 

<val ue>valeurl</val ue> 
<val ue>valeur2</val ue> 
</set> 
</property> 

Le tag set encadre la definition du contenu de la propriete, et le tag val ue specifie chaque 
valeur contenue dans la propriete. 

Le type java.util. List 

L'interface java.util . List est une collection ordonnee d'elements. A ce titre, ce type 
permet un controle precis de la facon dont chaque element est insere dans la liste. 

L'initialisation d'une propriete ayant ce type s'effectue grace au tag list, a utiliser en 
combinaison avec le tag property. 

Si nous ajoutons un attribut 1 ist de type java.util . List a notre Bean UnBean, nous devons 
ajouter la ligne suivante dans notre configuration : 

<property name="l i st"> 
<list> 

<val ue>valeurl</val ue> 
<val ue>valeur2</val ue> 
</list> 
</property> 

Le tag list encadre la definition du contenu de la propriete, et le tag value specifie 
chaque valeur contenue dans la propriete. Comme il s'agit d'une collection ordonnee 
d'elements, l'ordre de definition des valeurs est pris en compte. 
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Le type java.util. Properties 

Comme nous l'avons vu precedemment, il est possible d'initialiser une propriete de type 
java.util .Properties directement a partir d'une chaine de caracteres. Spring propose 
cependant une autre methode, plus lisible, a base de tags. 

L'initialisation d'une propriete ayant ce type s'effectue grace aux tags props et prop, a 
utiliser en combinaison avec le tag property. 

Nous pouvons done remplacer l'initialisation de l'attribut proprietes par la configuration 
suivante : 

<property name="proprietes"> 
<props> 

<prop key="l og4j . rootl_ogger"> 

DEBUG, CONSOLE 
</prop> 

<prop key="log4j. logger. tudu"> 

WARN 
</prop> 
</props> 
</property> 



Injection des collaborateurs 

Nous venons de voir comment initialiser les valeurs simples ainsi que les structures de 
donnees au sein d'un objet gere par le conteneur leger. Spring supporte en standard les 
types les plus frequemment rencontres pour les attributs d'une classe. II fournit en outre 
les transformateurs necessaires pour convertir la configuration effectuee sous forme de 
chaines de caracteres en une valeur ayant le type convenu. 

Nous allons nous interesser a present a l'injection des proprietes particulieres que sont 
les collaborateurs. 

Comme nous l'avons deja indique, la terminologie de Spring designe par le terme colla- 
borateur une propriete d'un Bean etant elle-meme un Bean gere par le conteneur leger. 
Pour realiser l'injection des collaborateurs, Spring propose deux methodes, l'une expli- 
cite, chaque collaborates etant defini dans le fichier de configuration, et 1' autre automatique, 
le conteneur leger decidant lui-meme des injections a effectuer (autowiring) par intros- 
pection des Beans. 

Une fois l'injection effectuee, il est possible de proceder a une verification des dependances 
afin de s'assurer que les Beans ont ete correctement initialises. 

Injection explicite des collaborateurs 

L'injection explicite des collaborateurs est la maniere la plus sure de gerer les dependan- 
ces entre les Beans geres par le conteneur leger, car toute la mecanique d'injection est 
sous controle du developpeur (contrairement a l'injection automatique, oil Spring prend 
des decisions). 
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Comme explique precedemment, les collaborateurs sont des proprietes. A ce titre, ils se 
configurent a l'aide du tag property. Cependant, le tag ou le parametre value sont ici 
remplaces par le tag ou le parametre ref, signifiant reference. 

Ainsi, la classe tudu. service. impl .ConfigurationManagerlmpl , qui ne possede qu'une 
propriete collaborateur, propertyDAO, est definie de la maniere suivante dans le fichier 
applicationContext.xml : 

<bean id="conf igurationManager" 

cl as s=" tudu. service. impl .ConfigurationManagerlmpl "> 
<property name="propertyDAO"> 
<ref bean="propertyDAO"/> 

</property> 
</bean> 

La ligne en gras montre comment utiliser le tag ref. Celui-ci possede un parametre bean 
qui contient le nom de l'objet a injecter dans la propriete propertyDAO. Ce Bean property- 
DAO est defini non pas dans le fichier applicationContext.xml, mais dans le fichier appli- 
cationContext-hibernate.xml. Si les deux Beans avaient ete definis dans le meme 
fichier de configuration, nous aurions pu remplacer le parametre bean par le parametre 
1 ocal , qui sert a specifier les Beans locaux a un fichier. 

Comme le tag value, le tag ref peut etre remplace par le parametre ref dans le tag 
property pour une ecriture plus concise. Ce parametre est l'equivalent de ref bean. II n'y 
a pas de raccourci pour ref local. Nous pouvons done modifier l'exemple precedent de 
la maniere suivante : 

<bean id="conf igurationManager" 

cl ass=" tudu. service. impl .ConfigurationManagerlmpl "> 
<property name="propertyDAO" ref="propertyDAO"/> 

</bean> 

Pour injecter un Bean, il n'est pas necessaire qu'il soit defini separement aupres du 
conteneur leger. II est possible de le declarer pour une injection unique a l'interieur d'un 
tag property. Pour configurationManager, par exemple, nous pouvons remplacer le tag ref 
par une definition interne du Bean propertyDAO : 

<bean id=" configurationManager" 

class=" tudu. service. impl .ConfigurationManagerlmpl "> 
<property name="propertyDAO"> 
<bean class="tudu.domain.dao.hibernate3.PropertyDA0Hibernate"> 
<property name="sessionFactory"> 
<ref bean="sessionFactory" /> 
</property> 
</bean> 
</property> 
</bean> 
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II n'est pas utile de nommer un Bean interne, puisqu'il n'est pas visible en dehors de la 
definition dans laquelle il s'inscrit. 

Injection automatique des collaborateurs 

Nous avons vu que 1' injection explicite impliquait l'ecriture de plusieurs lignes de confi- 
guration. Sur des projets de grande taille, les configurations peuvent rapidement devenir 
imposantes. Pour reduire de maniere drastique le nombre de lignes de configuration, 
Spring propose un mecanisme d'injection automatique, appele autowiring. 

Ce mecanisme utilise des algorithmes de decision pour savoir quelles injections realiser. 
L' autowiring est active Bean par Bean par le biais du parametre autowi re du tag bean, ce 
qui permet d'utiliser ce mode d'injection de maniere ciblee. 

Par defaut, l'autowiring n'est pas active. Son activation implique le choix de l'algorithme 
de decision parmi les quatre proposes par Spring : 

• byName : Spring va rechercher un Bean ayant le meme nom que la propriete pour 
realiser l'injection. 

• byType : Spring va rechercher un Bean ayant le meme type que la propriete pour 
realiser l'injection. S'il y en a plus d'un, une exception est generee. Si aucun Bean 
n'est trouve, la propriete est initialisee a nul 1 . 

• constructor : similaire a l'algorithme, mais fonde cette fois sur les parametres du 
constructeur de la propriete. 

• autodetect : selectionne automatiquement la recherche par le type ou par le construc- 
teur. La premiere est utilisee s'il existe un constructeur par defaut (c'est-a-dire sans 
arguments). 

Par exemple, dans Tudu Lists, nous pourrions activer l'autowiring pour nos Beans mana- 
ger declares dans applicationContext.xml. Nous pourrions utiliser indifferemment la 
methode par nom (les proprietes ont le meme nom que le Bean a injecter) ou par type (il 
n'y a qu'une seule implementation par type). En revanche, la methode par constructeur 
n'est pas adaptee, puisque les DAO n'ont que des constructeurs par defaut, done indiffe- 
rentiables. Lautodetection peut aussi etre utilisee, mais elle revient au meme que d'utiliser 
la methode par type. 

Si nous reprenons le Bean configurationManager, nous pouvons ecrire sa definition de la 
maniere suivante, plus concise que la precedente : 

<bean id="configurationManager" autowi re="byName" 

class="tudu.service.impl .ConfigurationManagerlmpl "/> 

Ainsi, l'utilisation de l'injection automatique permet de reduire de maniere significative 
le volume du fichier de configuration. Cependant, nous conseillons de ne pas abuser de ce 
mode d'injection, car il ne fait plus apparaitre explicitement les liaisons entre les differents 
Beans du conteneur. 
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Verification des dependences 

Spring offre la possibilite de s' assurer que les proprietes des Beans ont ete initialisees, 
soit de maniere explicite, dans le fichier de configuration, soit de maniere implicite, avec 
1' autowiring. 

Comme pour l'autowiring, la verification des dependances se regie au niveau du tag bean, 
grace au parametre dependency-check, permettant ainsi de cibler l'utilisation de cette fonc- 
tionnalite. 

La verification des dependances peut prendre l'une des trois formes suivantes : 

• simple : seules les proprietes simples (int, float, etc.) et les structures de donnees sont 
verifiees. Les collaborateurs ne le sont pas. 

• object : seuls les collaborateurs sont verifies. 

• all: combinaison des deux formes precedentes. 

Si nous reprenons le Bean conf igurationManager, nous pouvons enclencher la verification 
des dependances de la maniere suivante : 

<bean id="configurationManager" dependency-check="object" 
class="tudu.service.impl . ConfigurationManagerlmpl "> 
<property name="propertyDAO" ref="propertyDAO"/> 
</bean> 



Techniques avancees 

Nous venons de parcourir les differentes possibilites offertes par Spring pour l'injection 
des collaborateurs et la verification des dependances. 

Nous abordons a present des techniques avancees proposees par Spring pour aller encore 
plus loin dans la definition des Beans d'une application, notamment pour l'expression 
des dependances et la creation de Beans. 

Definitions abstraites de Beans et heritage 

Pour remedier au probleme de duplication de lignes de configuration d'un Bean a un 
autre, Spring propose un mecanisme d'heritage de configuration, comme pour l'approche 
orientee objet. II permet en outre de definir des Beans abstraits, c'est-a-dire qui ne sont 
pas instancies par le conteneur, de facon a concentrer les lignes de configuration reutili- 
sables. 

Si nous analysons le fichier applicationContext-hibernate.xml, nous constatons que les 
DAO ont tous la meme propriete, initialisee avec le meme collaborates. Nous pouvons 
done utiliser avantageusement 1' heritage de configuration pour rendre ce fichier plus 
concis. 
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Dans un premier temps, nous definissons un Bean abstrait, abstractDAO, destine a recevoir 
la configuration de la propriete commune a tous les Beans DAO : 

<bean id="abstractDAO" abstract="true"> 

<property name=" session Factory "> 
<ref bean="sessionFactory" /> 

</property> 
</bean> 

II n'est pas utile de preciser un type de Bean puisque celui-ci n'est pas destine a etre 
instancie par le conteneur. 

II suffit ensuite de faire heriter chaque DAO de ce Bean pour se dispenser de configurer 
chaque fois la propriete sessionFactory. Le code du DAO userDAO devient ainsi : 

<bean id="userDAO" parent="abstractDAO" 

class="tudu.domain.dao.hibernate3.LlserDA0Hibernate"/> 

Le principe est exactement le meme pour tous les autres DAO du fichier. 

Notons que l'heritage de configuration ne necessite pas de structure d'heritage au niveau 
objet (nos DAO sont independants les uns des autres). Ce mecanisme est strictement 
interne a la configuration des Beans. 

Support de nouveaux types pour les valeurs simples 

Les classes utilisees comme des types de proprietes n'ont pas forcement toutes vocation 
a etre gerees sous forme de Beans par le conteneur leger. II peut etre plus interessant de 
les traiter comme des valeurs simples, initialisees via une chaine de caracteres. 

Inconnus de Spring, ces types doivent etre accompagnes d'un transcodeur, a meme de 
faire la conversion entre la chaine de caracteres et les attributs du type. 

Nous devons done creer un editeur de proprietes, un concept issu du standard JavaBean, 
correspondant a notre transcodeur. C'est ce concept qu'utilise Spring pour supporter les 
differents types de valeurs simples que nous avons vus precedemment. 

Supposons que nous definissions de la maniere suivante une classe UnType destinee a etre 
utilisee dans le Bean monBean par la propriete attr : 

public class UnType { 
private String info; 

public String getlnfoO { 
return info; 

} 

public void setInfo(String info) { 
this. info = info; 

} 

} 
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Apres avoir ajoute la nouvelle propriete dans monBean ainsi que son accesseur et son 
modificateur, nous ecrivons la ligne de configuration suivante dans la definition du 
Bean : 

<property name="attr" val ue="test"/> 

Bien entendu, Spring ne connaissant pas le type UnType, une exception sera generee a 
1' execution. 

Pour creer un editeur, il suffit de deriver la classe org.springf ramework. beans. propertyedi - 
tors . PropertiesEditor. La nouvelle classe surcharge la methode setAsText, qui effectue la 
conversion proprement dite. Cette methode recoit pour unique parametre la chaine de 
caracteres specifiee dans la configuration. Une fois la conversion terminee, elle doit enre- 
gistrer le resultat obtenu, c'est-a-dire l'instance de UnType correctement initialisee, avec la 
methode setValue. 

Pour UnType, l'editeur a la forme suivante : 

import org.springf ramework. beans. propertyedi tors. PropertiesEditor; 

public class UnTypeEditor extends PropertiesEditor { 

public void setAsTexttString arg) 
throws IllegalArgumentException { 
UnType instance = new UnTypeO; 
instance. set Info (arg) ; 
setValue(instance) ; 




Dans notre cas, la conversion consiste tout simplement a creer une instance de UnType et a 
initialiser son attribut i nf o avec la chaine de caracteres issue du fichier de configuration. 

Pour que Spring sache oil trouver nos editeurs de proprietes specifiques, il existe deux 
possibilites : soit l'editeur se trouve dans le meme package que le type, et son nom est 
alors de la forme TypeEditor (ou Type correspond au nom du type, dans notre exemple 
UnTypeEditor), soit en ajoutant ces quelques lignes dans le fichier de configuration : 

<bean id="customEdi torConf igurer" 

cl ass= "org. spri ngf ramework. beans. factory .config.CustomEditorConfigurer"> 
<property name="customEdi tors"> 
<map> 

<entry key="packagel.UnType"> 

<bean cl ass="package2. UnTypeEditor "/> 
</entry> 
</map> 
</property> 
</bean> 
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Support de fabriques de Bean specif iques 

Les exemples que nous avons donnes jusqu'a present laissaient au conteneur leger la 
charge d'instancier et d'initialiser directement les Beans de notre application. Dans 
certains cas, il peut etre necessaire de ne pas deleguer cette creation, afin de realiser des 
traitements specifiques, non exprimables via le langage XML de configuration, par 
exemple. Ce support est souvent utilise pour integrer des applications existantes non 
fondees sur Spring et 1' injection de dependances. 

Afin de repondre a ce besoin, Spring propose plusieurs methodes pour implementer des 
fabriques de Bean specifiques. 

Utilisation d'une fabrique sous forme de Bean classique 

La methode la plus simple consiste a creer une classe fabrique disposant d'une methode 
sans parametre renvoyant une instance du Bean attendu. 

Par exemple, pour notre Bean monBean, nous pouvons developper une classe UneFabn'que, 
dont la methode creelnstance renvoie une instance vide de UnBean : 

public class UneFabn'que { 

public UnBean creelnstance( ) { 
return new UnBean( ) ; 

} 

) 

II suffit ensuite d'indiquer la classe prealablement definie sous forme de Bean et la 
methode de fabrication dans la configuration du Bean cible grace aux parametres 
factory-bean et factory-method : 

<bean id="maFabrique" class="UneFabrique"/> 

<bean id="monBean" cl ass="UnBean" 

factory-bean="maFabrique" factory-method="creeInstance"> 

(...)<!-- Initialisation des proprietes si necessai re--> 
</bean> 

Bien entendu, maFabrique etant un Bean, ses proprietes peuvent etre initialisees par 
Spring. 



Utilisation de I'interface FactoryBean 

Une methode plus complexe consiste a implementer I'interface FactoryBean du package 
org. springframework. beans. factory. Cette interface est tres utilisee par Spring en interne 
pour definir des fabriques specialisees pour certains types complexes. 

Par convention, le nom des implementations de cette interface est suffixe par FactoryBean. 
Cette technique s'avere pratique pour recuperer des instances qui ne peuvent etre creees 
directement avec un new. 
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Par exemple, une fabrique de ce type est utilisee pour creer une fabrique de session 
Hibernate (SessionFactory), l'outil de mapping objet-relationnel que nous aurons l'occasion 
d'aborder au chapitre 1 1 : 

<bean id="sessionFactory" 

class="org.springf ramework.orm. hi bernate3. Local Session Factory Bean" > 

<property name="configLocation" 

value="classpath:hibernate.cfg.xml "/> 

</bean> 

La fabrique se declare sous la forme d'un Bean, comme avec la methode precedente, la 
seule difference etant qu'il n'est pas necessaire de specifier la fonction de creation des 
instances du Bean. En fait, la fabrique se substitue au type du Bean. 

En effet, les references a ce Bean correspondent non pas a 1' instance de la fabrique, mais 
aux instances qu'elle cree. C'est la raison pour laquelle sessionFactory est utilise comme 
un Bean classique par les DAO, comme le montre l'extrait du fichier application- 
Context-hibernate.xml ci-dessous : 

<bean id="todoDA0" 

class="tudu.domain.dao.hibernate3.TodoDA0Hibernate"> 
<property name=" ses si on Factory "> 
<ref bean="sessionFactory" /> 
</property> 
</bean> 

Si nous reprenons notre exemple precedent, la fabrique prend la forme suivante : 
import org. springf ramework. beans. factory . Factory Bean; 



public class UneFabrique implements FactoryBean { 
public Object getObjectO throws Exception { 
return new UnBean( ) ; 

} 



public Class getObjectType( ) { 
return UnBean. class; 

} 



public boolean isSingleton( ) { 
return false; 

} 

} 

La methode getObject renvoie l'instance demandee a la fabrique, tandis que la methode 
getObjectType renvoie le type de Bean cree par la fabrique. La fonction i sSi ngl eton indique 
pour sa part si la fabrique cree des singletons ou des prototypes. 

Nous pouvons maintenant configurer monBean pour utiliser cette nouvelle fabrique : 

<bean id="monBean" class="UneFabrique" /> 
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Notons la disparition de 1' initialisation de proprietes de UnBean. L' initialisation qui doit 
figurer a la place est celle de la fabrique du Bean, et non du Bean en lui-meme. Or 
UneFabrique n'ayant pas de proprietes, il n'y a pas lieu a avoir d' initialisation dans cette 
definition. 

En conclusion, par rapport a la methode precedente, la fabrique de Bean a ici Pentiere 
responsabilite de la creation de l'instance du Bean ainsi que de son initialisation. Remar- 
quons que nous pouvons recuperer l'instance du FactoryBean lui-meme en prefixant le 
nom du Bean avec &. 

Support des methodes de recherche 

Certaines classes ont besoin de methodes specifiques pour rechercher un composant de 
P application (ou externe) dont elles ont besoin. Plutot que de les developper directement 
au sein de ces classes, Spring permet de les externaliser au sein de Beans dedies. Ces 
Beans dedies sont ensuite sollicites via une methode definie dans les classes utilisatrices. 
Cette methode peut etre abstraite ou concrete. Dans le dernier cas, le traitement associe 
est remplace par celui du Bean dedie. 

Supposons que monBean ait besoin d'une instance de UnService, dont la recuperation 
necessite un traitement particulier, plus complexe qu'un simple new ou qu'une injection. 
Pour cela, nous definissons une methode abstraite, appelee getService. Le code de cette 
methode est externalise dans le Bean servi ceFi nder, qui possede une methode concrete de 
meme nom. 

Grace a la configuration suivante, utilisant le tag lookup-method, Spring remplace la 
methode abstraite definie dans monBean par la methode concrete definie dans servi ceFin- 
der : 

<bean id="serviceFinder" class="ServiceFinder"/> 

<bean id="monBean" cl ass="llnBean"> 

<lookup-method name="getService" bean="serviceFinder"/> 
</bean> 

Cette substitution s'effectuant directement au niveau du bytecode de P application, la 
JVM considere que monBean est une classe concrete, alors que son code source mentionne 
Pexistence d'une methode abstraite. 



En resume 

Nous avons vu dans cette section Pessentiel des outils fournis par Spring pour initialiser 
les objets et gerer leurs dependances. 

En supportant plusieurs modeles d'injection et d'instanciation (injection par modifica- 
teur, par constructeur, explicite, automatique ou utilisation d'une fabrique specifique), 
Spring est capable de gerer tout type de Bean au sein de son conteneur leger. 
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Cycle de vie des Beans et interactions avec le conteneur 

Au sein du conteneur leger, chaque Bean suit un cycle de vie qui va de sa creation jusqu' a 
sa destruction. La gestion de ce cycle de vie est de la responsabilite du conteneur leger. 
Spring propose cependant divers moyens pour que les Beans puissent etre avertis en 
fonction des differentes etapes de leur cycle de vie. 

Spring permet en outre aux objets d' avoir un acces direct a la fabrique de Bean ou au 
contexte d' application grace a des interfaces specifiques, que les Beans interesses doivent 
implementer. 

Enfin, Spring offre la possibilite de mettre en place des post-processeurs destines a effec- 
tuer des traitements, suite aux operations executees par le conteneur leger. 

Cycle de vie des Beans 

Le cycle de vie de chaque Bean comporte une naissance et une mort. Dans le cadre du 
conteneur leger de Spring, la naissance de l'ensemble des Beans s'effectue au demarrage 
de celui-ci par defaut. Cela induit un temps de chargement plus long de 1' application 
mais presente l'avantage de s' assurer des le demarrage que la creation des Beans ne 
posera pas de probleme. Ce comportement peut etre modifie en positionnant le parametre 
1 azy-init du tag bean a fal se. 

Si nous desirons signaler que le Bean userManager ne doit etre cree qu'au dernier moment, 
il suffit d'ecrire le code suivant : 

<bean id="userManager" cl ass="tudu. service. impl .UserManagerlmpl " 
lazy-init="true"/> 

La mort des Beans depend de leur nature. S'il s'agit de prototypes, ceux-ci disparaissent 
des lors que plus aucun objet ne les reference et que le ramasse-miettes a fait son ceuvre. 
Spring ne conservant pas de reference en interne pour les prototypes, il n'a pas « cons- 
cience » de leur mort. Par contre, il conserve une reference pour chaque singleton dont il 
a la charge. II a done « conscience » de leur mort, ce qui permet de realiser des traite- 
ments lorsque celle-ci survient. 

Traitement lors de la creation d'un Bean 

Pour executer un traitement lors de la creation d'un Bean specifique, Spring propose 
deux methodes. La premiere consiste a utiliser le parametre im't du tag bean, et la 
seconde a faire implementer au Bean l'interface Initial izingBean du package org. spring- 
framework. beans .factory. 

Nous conseillons d' utiliser la premiere methode, car elle est moins intrusive dans le code 
de l'application que la seconde, qui oblige a creer une dependance explicite entre l'appli- 
cation et l'API de Spring. 
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Si nous voulons executer un traitement lors de la creation de monBean en utilisant la 
premiere methode, il suffit d'initialiser le parametre init du tag bean en lui indiquant le 
nom de la methode UnBean a appeler : 

<bean id="monBean" cl ass="UnBean" init="initialise"> 

(...) 
</bean> 

Ici, la methode initialise de la classe UnBean est appelee des que monBean est cree. Cette 
methode ne prend aucun parametre et ne renvoie aucun resultat (void). 

La seconde methode necessite que la classe UnBean implemente l'interface Initial 1zi ngBean : 

import org. springframework. beans. factory. I nitializi ngBean; 

(...) 

public class UnBean implements InitializingBean { 

(...) 

public void afterPropertiesSet( ) { 

// intialise 

} 

} 

La methode afterPropertiesSet est l'equivalent de la methode initialise abordee prece- 
demment. 

Traitement lors de la destruction d'un Bean 

Comme pour la creation d'un Bean, Spring propose deux methodes pour executer des 
traitements lors de sa destruction. La premiere consiste a utiliser le parametre destroy- 
method du tag bean, et la seconde a faire implementer au Bean l'interface DisposableBean 
du package org. springframework. beans. factory. La encore, nous conseillons d'utiliser la 
premiere methode plutot que la seconde. 

Si nous voulons executer un traitement lors de la destruction de monBean en utilisant la 
premiere methode, il suffit d'initialiser le parametre destroy-method du tag bean en lui 
indiquant le nom de la methode UnBean a appeler : 

<bean id="monBean" cl ass="UnBean" destroy-method="detruit"> 
(...) 

</bean> 

Ici, la methode detruit de la classe UnBean est appelee des que monBean est en passe d'etre 
detruit. Cette methode ne prend aucun parametre. 

La seconde methode necessite que la classe UnBean implemente l'interface Di sposabl eBean : 

import org. springframework. beans. factory. DisposableBean; 

(...) 

public class UnBean implements DisposableBean { 



(...) 
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public void destroyO { 
// detruit 

} 

} 

La methode destroy est l'equivalent de la methode detruit abordee precedemment. 

Recuperation du nom du Bean 

Dans certains cas, il peut etre utile que la classe d'un Bean connaisse le nom de ce 
dernier. Pour permettre cela, Spring dispose de l'interface BeanNameAware du package 
org. springframework. beans. factory. 

Cette interface dispose d'une methode unique, setBeanName, qui est appelee par le conte- 
neur leger pour indiquer a 1' implementation le nom du Bean auquel elle correspond. 
Nous conseillons de limiter au maximum 1' utilisation de cette interface, car elle cree une 
dependance explicite avec l'API Spring. 

Nous pouvons modifier la classe UnBean arm qu'elle ait acces au nom du Bean correspondant 
a ses instances : 

import org. springframework. beans .factory .BeanNameAware; 

(...) 

public class UnBean implements BeanNameAware { 
private String beanName; 

(...) 

public void setBeanName(String name) { 

this. beanName = name; 

} 

} 

Acces a la fabrique de Bean ou au contexte d'application 

Certains Beans peuvent avoir besoin d'acceder a la fabrique de Bean ou au contexte d'appli- 
cation pour leurs traitements. Pour cela, Spring fournit deux interfaces, BeanFactoryAware 
dans le package org. springframework. beans, factory pour la fabrique de Bean et Application- 
ContextAware dans le package org. springframework. context pour le contexte d'application. 

Nous pouvons modifier la classe UnBean afin qu'elle ait acces a la fabrique de Bean : 

import org. springframework. beans .factory .BeanFactoryAware; 

(...) 

public class UnBean implements BeanFactoryAware { 
private BeanFactory beanFactory; 

(...) 

public void setBeanFactory(BeanFactory beanFactory) { 
this. beanFactory = beanFactory; 

} 

} 
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Pour acceder aux fonctionnalites supplementaires offertes par les differentes implemen- 
tations de cette interface, il est bien entendu possible d'effectuer un transtypage (cast). 

De la meme maniere, la classe UnBean peut avoir acces au contexte d'application : 

import org. springframework. beans. context. ApplicationContextAware; 

(...) 

public class UnBean implements Appl icationContextAware { 
private Appl icationContext appl icationContext; 
(...) 

public void setApplicationContexttApplicationContext ac) { 

this. appl icationContext = ac; 

} 

La encore, il est possible d'effectuer un transtypage pour acceder aux fonctionnalites 
specifiques des implementations de cette interface. 

Les post-processeurs 

Spring definit plusieurs interfaces permettant de creer des post-processeurs. Ces post- 
processeurs sont appeles a la fin de certaines operations specifiques effectuees par le 
conteneur leger. lis sont ainsi en mesure d'influer sur le resultat de ces operations. 

Nous detaillons dans cette section les deux post-processeurs de base de Spring : le post- 
processeur de Bean et le post-processeur de fabrique de Bean. 

Les post-processeurs sont automatiquement charges par les contextes d'application des 
lors qu'ils sont definis sous forme de Bean dans le fichier de configuration. Si 1' application 
utilise seulement une fabrique de Bean, la solution est specifique du type de post-processeur 
(voir plus loin). 

Le post-processeur de Bean 

Un post-processeur de Bean est appele par le conteneur leger des qu'un nouveau Bean est 
cree. Deux moments sont identifies dans le processus de creation : avant l'initialisation 
des proprietes du Bean et apres. Cette notion est materialisee par l'interface BeanPostPro- 
cessor, definie dans le package org. springframework. beans. factory. config. 

Pour illustrer l'utilisation de cette interface, nous pouvons creer un post-processeur de Bean, 
qui signalera sur la console toutes les creations de Beans, avant et apres leur initialisation : 

import org. springframework. beans. factory. config. Bean Post Processor; 

public class PostProcBean implements BeanPostProcessor { 

public Object postProcessAfterInitialization(Object bean 

.String beanName) { 
System. out. printlnCApres initialisation de "+beanName); 
return bean; 

} 



Le conteneur leger de Spring 



Chapitre 3 



public Object postProcessBeforeInitialization(Object bean 

.String beanName) { 
System. out. printlnCAvant initialisation de "+beanName); 
return bean; 

} 

} 

Les deux mefhodes postProcess renvoient l'instance du Bean qu'elles recoivent en para- 
metre. En effet, puisqu'elles sont en mesure de modifier ce bean, elles doivent renvoyer le 
resultat de leurs operations. 

Pour que le contexte d'application charge ce post-processeur, il est necessaire de le definir 
sous forme de Bean : 

<bean id="postProcBean" cl ass="PostProcBean"/> 

Notre post-processeur sera ainsi appele avant et apres chaque initialisation d'un Bean au 
sein du conteneur leger. 

Si l'application n'utilise pas de contexte d'application, il est necessaire d'enregistrer le 
post-processeur aupres de la fabrique de Bean. Pour cela, nous utilisons la methode 
addBeanPostProcessor de l'interface Conf i gurabl eBeanFactory. Bien entendu, cela suppose 
que 1' implementation de la fabrique de Bean implemente cette interface, mais c'est gene- 
ralement le cas, notamment pour Xml BeanFactory. 

Le post-processeur de fabrique de Bean 

Le post-processeur de fabrique de Bean est utilise pour modifier la configuration de la 
fabrique de Bean suite a sa creation. Cette notion est materialisee par l'interface BeanFacto- 
ry Post Processor du package org. springframework. beans. factory. conf ig. 

Comme il s'agit ici de configuration, seules les fabriques implementant l'interface Conf i - 
gurabl eBeanFactory sont supportees. Le code suivant montre comment creer un post- 
processeur de fabrique de Bean : 

import org.springf ramework. beans. factory .conf ig. Bean Factory Post Processor; 
import org.springf ramework. beans. factory .conf ig 
.Conf i gurabl e Li stabl eBeanFactory; 

public class PostProcFactBean implements BeanFactoryPostProcessor { 

public void postProcessBeanFactory 
(ConfigurableListableBeanFactory beanFactory) { 
//modification des parametres de la fabrique 

} 

} 

A nouveau, il est necessaire de definir ce post-processeur sous forme de Bean dans le 
fichier de configuration de Spring afin que le contexte d'application le charge automati- 
quement. 
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Si l'application n' utilise pas de contexte d' application, il est necessaire d'executer 
manuellement le post-processeur apres que la fabrique de Bean a ete creee, en appelant la 
methode postProcessBean Factory dans le code de l'application. 

Fonctionnalites additionnelles du contexte d'application 

Nous avons passe en revue l'essentiel des fonctionnalites du conteneur leger. La notion 
de contexte d'application, qui englobe le conteneur leger, offre toutefois des fonctions 
utilitaires supplementaires, qui sont utiles aux applications. 

Nous detaillons dans cette section les deux principales d'entre elles que sont le support 
de l'internationalisation et l'abstraction des acces aux ressources. 

Support de l'internationalisation 

L'internationalisation des applications avec Java est assuree via des fichiers de proprietes (un 
par langue) associant une cle et un message. En fonction de la localisation de l'application, 
la JVM selectionne le fichier de proprietes adequat, qui doit se trouver dans le classpath. 

Elle se fonde pour cela sur le nom du fichier, qui doit etre suffixe par le code ISO du pays 
(par exemple messages_FR.properties pour les messages en francais). Si le fichier de 
proprietes ne specifie pas de code ISO, il est considere comme le fichier par defaut qui 
sera utilise si l'application n'est pas en mesure d'identifier la langue dans laquelle elle 
doit fonctionner. 

Pour en savoir plus sur le format de ces fichiers, nous invitons le lecteur a lire la javadoc 
concernant la classe java.util .ResourceBundle, qui est celle utilisee pour acceder aux 
messages. 

Pour Tudu Lists, le seul fichier de message fourni est messages.properties, qui se trouve 
dans le repertoire JavaSource. Dans notre application exemple, les messages sont 
uniquement utilises dans les pages JSP. Nous n'avons done pas besoin du support de 
Spring dans ce domaine, la taglib standard JSTL etant suffisante. 

Si nous avions eu besoin d'utiliser un fichier de proprietes au sein meme de nos Beans, 
une alternative se serait presentee : soit utiliser la classe ResourceBundle directement, soit 
beneficier du support de Spring. L'avantage de la premiere solution est qu'elle est parfai- 
tement standard, tandis que celui de la seconde est d'offrir davantage de possibilites, 
principalement l'agregation de ResourceBundles. 

Spring dispose de sa propre notion de ResourceBundl e, qui permet d'agreger le contenu de 
plusieurs fichiers de proprietes. Pour effectuer cette operation, il sufht de creer un Bean 
de type ResourceBundleMessageSource (package org. springf ramework. context. support) de 
la maniere suivante : 



<bean id="messageSource" 

cl ass=" org. springf ramework. context. support. ResourceBundl eMessageSource"> 
<property name="basenames"> 
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<list> 

<val ue>messages</value> 
<val ue>excepti ons</val ue> 

</list> 
</property> 
</bean> 

Ce type possede une propriete basenames, qui contient la liste des noms des Resource- 
Bundl es a agreger (sans le code ISO). Dans cet exemple, nous avons specifie deux Resour- 
ceBundles, msg et exceptions. Pour la langue francaise, Spring charge done 
messages_FR.properties et exceptions_FR.properties ou les fichiers par defaut (e'est- 
a-dire sans le code ISO en suffixe), si les precedents n'existent pas. 

Pour recuperer un message, il suffit d'appeler l'une des methodes getMessage du contexte 
d' application. Pour rappel, nous pouvons obtenir le contexte d' application en implementant 
l'interface Appl icationContextAware. 

Le code suivant illustre l'utilisation des deux methodes getMessage avec le contenu de 
messages.properties de Tudu Lists : 

String welcomel = applicationContext 

. getMessage ( "menu. wel come" .null ,1 ocal e) ; 
String welcome2 = applicationContext 

. getMessage ( "menu. wel come" .null , "wel come" , 1 ocale) ; 

Le parametre locale (de type java.util .Locale) specifie la localisation a utiliser pour 
selectionner la langue du message. S'il vaut nul 1 , le choix de la langue est realise par la 
JVM. 

Le dernier appel permet de definir une valeur par defaut si le message correspondant a la 
cle n'est pas trouve. Le second genere une exception si nous nous trouvons dans ce cas de 
figure. 

Le parametre a nul 1 dans les deux appels correspond aux parametres a substituer dans le 
message. II s'agit d'un tableau d'objets, generalement des chaines de caracteres. En effet, 
Java permet de definir dans un texte des variables qui seront specifiees au moment de 
1' execution. 

Dans messages.properties, le message register. user. a 1 ready .exi sts prend typiquement 
un parametre qui est, en l'occurrence, le nom de l'utilisateur qui existe deja : 

register. user. already. exists^User login "{0}" already exists. 

Pour recuperer ce message correctement parametre, il suffit d'ecrire : 

String erreur = applicationContext 

.getMessage ("register. user. al ready. exi sts" 

,new 0bject[] {username}. locale); 

La variable username contient bien entendu le nom de l'utilisateur qui tente de s'enregistrer. 
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Abstraction des acces aux ressources 

Les ressources (fichiers) utilisees par une application peuvent avoir de multiples 
supports. II peut s'agir de ressources disponibles sur un serveur Web via le protocole 
HTTP, sur le systeme de fichiers de la machine, dans le classpath, etc. 

Java ne propose malheureusement pas de mecanisme d' acces unique a ces ressources en 
faisant abstraction du support qu'elles utilisent. Par exemple, pour acceder a un fichier 
sur un serveur Web, nous disposons de la classe java.net. URL, mais celle-ci n'est pas 
utilisable pour les ressources accessibles depuis le classpath. 

Pour combler ce manque, Spring definit deux notions : la ressource et le chargeur de 
ressources. Comme d'habitude, ces deux notions sont materialisees sous forme 
d' interfaces. 

L'interface Resource possede plusieurs implementations, disponibles dans le package 
org. springframework. core. io : Fi 1 eSystemResource pour les ressources stockees dans le 
systeme de fichiers, CI assPathSystemResource pour celles qui sont accessibles depuis le class- 
path, etc. La notion de ressource ne presuppose pas l'existence de la ressource. C'est la 
raison pour laquelle, elle dispose de la fonction booleenne exists. 

La notion de chargeur de ressource est implemented par les contextes d'application qui 
disposent de la methode getResource. Cette methode, definie par l'interface Resource- 
Loader, prend pour unique parametre le chemin de la ressource sous forme d'une chaine 
de caracteres. Ce chemin peut etre soit relatif, soit absolu. Dans le second cas, le format de 
ce parametre est celui d'une URL. Cette URL supporte HTTP, file et classpath, afin de 
designer respectivement les ressources disponibles sur un serveur Web, dans le systeme 
de fichiers ou depuis le classpath. 

Spring propose une interface ResourceLoaderAware pour les Beans ayant besoin de charger 
des ressources. II leur suffit de l'implementer pour que le contexte d'application se 
charge de leur fournir 1' instance de chargeur dont ils ont besoin via la methode 
setResourceLoader. Bien entendu, si le Bean a deja acces au contexte d'application (via 
ApplicationContextAware), 1' implementation de cette interface n'est pas necessaire, puisque 
ce dernier l'implemente directement. 

Si notre Bean monBean a besoin de charger des ressources et qu'il n'ait pas acces au 
contexte d'application, nous pouvons ecrire : 

import org. springframework. context. ResourceLoaderAware; 

(...) 

public class UnBean implements ResourceLoaderAware { 
private ResourceLoader loader; 
(...) 

public void setResourceLoadertResourceLoader loader) { 
this. loader = loader; 

} 

} 



Le conteneur leger de Spring 



Chapitre 3 



Une fois un chargeur disponible, nous utilisons ses services pour acceder aux ressources. 

Le code suivant utilise le contexte d' application pour recuperer une ressource disponible 
sur le Web, une ressource stockee dans le systeme de fichiers et une ressource accessible 
depuis le classpath : 

Resource rl = applicationContext.getResource("http://tudu. sf.net/index. html"); 
Resource r2 = applicationContext.getResource("file:c:/temp/fichier.txt"); 

Resource r3 = applicationContext.getResource("classpath:tudu/domain/model/User.hbm.xml "); 

Une fois les ressources recuperees, elles peuvent etre manipulees a l'aide des methodes 
getFile et getURL de l'interface Resource, puisque ces deux methodes renvoient respecti- 
vement un objet de type j ava . i o . Fi 1 e ou un objet de type j ava . net . URL. 

Ajoutons que Spring offre la possibilite de transformer des instances de la classe 
java.io.InputStream et des tableaux de bytes en ressources. Pour cela, il suffit d'instan- 
cier respectivement les classes InputStreamResource et ByteArrayResource avec le flux ou le 
tableau en parametre. II n'est pas ici necessaire d'utiliser un chargeur de ressource. 



Publication d'evenements 

Le contexte d' application a la possibilite de publier des evenements destines a des obser- 
vateurs. Cette publication s'effectue via la methode publishEvent definie par l'interface 
org. springf ramework. con text . Appl i cat ion Even tPubl is her et implementee par les contextes 
d' application. 

Un evenement est un objet heritant de la classe Appl icationEvent du package org. spring- 
framework. context. Cette classe definit deux methodes : getTimeStamp, qui donne l'instant 
auquel l'evenement a ete genere, et getSource, qui donne l'objet source de l'evenement. 
La source de l'evenement est initialisee via 1' unique parametre du constructeur de cette 
classe. 

Nous pouvons definir un evenement de la maniere suivante : 
import org. springf ramework. context. Appl icationEvent; 

public class UnEvenement extends Appl icationEvent { 

public UnEvenement(Object source) { 
super(source) ; 

} 

) 

Un observateur est un objet dont la classe implemente l'interface Appl icationListener. 
Cet observateur recoit tous les evenements publies par le contexte d' application. Cette 
interface specifie une methode onAppl icationEvent, qui est appelee des qu'un evenement 
est genere. Cette methode prend en unique parametre l'evenement en question. 
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Pour traiter l'evenement precedent, nous pouvons developper l'observateur suivant : 

import org. spring-framework, context. Appl i cation Listener; 
import org. springf ramework. context. Appl i cat ion Event; 

public class UnObservateur implements Appl icationListener { 

public void onApplicationEventtApplicationEvent evt) ( 
if(evt instanceof UnEvenement) { 
// traitement de l'evenement 

} 

} 

} 

Cet observateur doit ensuite etre declare sous forme de Bean dans le fichier de confi- 
guration, afin que le contexte d'application puisse l'avertir a chaque publication d'evene- 
ment : 

<bean id="unObservateur" cl ass="UnObservateur"/> 

Pour generer un evenement, il suffit de creer une instance de la classe UnEvenement et de la 
publier via la methode publ ishEvent du contexte d'application : 

appl icationContext .publ ishEvent (new UnEvenement( ) ) ; 

Bien entendu, pour que cette operation soit possible, il est necessaire que le Bean gene- 
rant cet evenement ait acces au contexte de 1' application. Sinon, il a la possibilite 
d'implementer l'interface Appl icationEventPubl isherAware du package org.springfra- 
mework. context, qui fonctionne selon les memes principes que les precedentes interfaces 
de type Aware. 

Pour illustrer l'utilisation de cette interface, nous pouvons modifier notre classe UnBean de 
la maniere suivante : 

import org. springf ramework. context. Appl icationEventPubl isherAware; 
import org. springf ramework. context. Appl icationEventPubl is her; 

public class UnBean implements ApplicationEventPublisherAware { 
(...) 

private Appl icationEventPubl isher publisher; 

public void setAppl icationEventPubl isher 
(Appl icationEventPubl isher publisher) { 
this. publ isher = publisher; 

} 

(...) 

} 

Le Bean monBean peut de la sorte generer des evenements en utilisant la methode 
publ ishEvent de son attribut publisher. 

L' application Tudu Lists utilise l'interface Appl icationListener pour afficher un 
message au demarrage de 1' application Web. Cet affichage est gere dans la classe 
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tudu. service. impl .TodoLi stsManagerlmpl , dont nous reproduisons une partie du code ci- 
dessous : 

(...) 

import org.springf ramework. context. Appl i cat ion Listener; 

import org.springf ramework. context. event. Context Refreshed Event; 

public class TodoListsManagerlmpl implements TodoListsManager, 

Appl icationListener ( 

(...) 

public void onApplicationEvent(ApplicationEvent event) { 
if (event instanceof ContextRef reshedEvent) { 
log.warnCSpring context is starting up : " 
+ event. toString( ) ) ; 

} 

} 

(...) 

} 

Cette classe utilise l'evenement standard de Spring ContextRefreshedEvent pour detecter 
le chargement du contexte d' application signifiant le demarrage de Tudu Lists. 

Conclusion 

Nous avons vu dans ce chapitre comment utiliser les differentes fonctionnalites du conteneur 
leger de Spring. 

Nous avons etudie les differentes methodes d'injection, ainsi que la facon dont sont crees 
les Beans geres par le conteneur leger et leur cycle de vie. Nous avons vu en outre 
comment les Beans peuvent s'interfacer etroitement avec le conteneur via l'implemen- 
tation d'interfaces. Ce dernier point doit cependant etre limite au strict necessaire, car il 
cree une dependance explicite entre les Beans de 1' application et l'API de Spring. 

Pour terminer, nous avons decrit les fonctionnalites additionnelles qu'apporte le contexte 
d' application a la fabrique de Bean. 

Si nous reprenons la modelisation proposee pour Tudu Lists au chapitre 2 (voir 
figure 2.7), nous constatons que le contenu des fichiers de configuration des projets 
applicationContext.xml et applicationContext-hibernate.xml la reproduit exacte- 
ment. Spring nous a done permis d'atteindre la modelisation optimale que nous avons 
definie. 

Ce chapitre a effectue une plongee dans le coeur meme de Spring, sur lequel repose une 
grande partie de l'edifice. Certaines activites, comme la gestion des transactions, ne 
peuvent toutefois se satisfaire uniquement du conteneur leger. C'est la raison pour 
laquelle Spring s'est dote d'un support de la POA, que nous presentons au chapitre 
suivant. 
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La POA (programmation orientee aspect), ou AOP (Aspect-Oriented Programming), est 
un nouveau paradigme, dont les fondations ont ete definies au centre de recherche Xerox, 
a Palo Alto, au milieu des annees 1990. Par paradigme, nous entendons un ensemble de 
principes qui structurent la maniere de modeliser les applications informatiques et, en 
consequence, la facon de les developper. 

La POA a emerge a la suite de differents travaux de recherche, dont l'objectif etait 
d'ameliorer la modularite des logiciels afin de faciliter la reutilisation et la maintenance. 
Elle ne remet pas en cause les autres paradigmes de programmation, comme l'approche 
procedurale ou l'approche objet, mais les etend en offrant des mecanismes complemen- 
taires pour mieux modulariser les differentes preoccupations d'une application et ameliorer 
ainsi leur separation. 

Le conteneur leger de Spring etant de conception orientee objet, il ne peut aller au-dela 
des limites fondamentales de ce paradigme. C'est la raison pour laquelle Spring dispose 
de son propre framework de POA, qui lui permet d' aller plus loin dans la separation des 
preoccupations. 

Pour les lecteurs qui ne connaitraient pas ce nouveau paradigme de programmation, ce 
chapitre donne une vision synthetique des notions cles de la POA disponibles avec 
Spring. Nous invitons ceux qui desireraient en savoir plus sur la POA a lire l'ouvrage 
Programmation orientee aspect pour Java/J2EE, publie en 2004 aux editions Eyrolles. 

Comme nous l'avons fait au chapitre 2 pour les concepts des conteneurs legers, nous 
commencons par decrire les problematiques rencontrees par les approches classiques de 
modelisation puis montrons en quoi la POA propose une solution plus elegante, avec ses 
notions d'aspect, de point de jonction, de coupe, de greffon et d' introduction. 
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Limites de I'approche orientee objet 

Comme indique au chapitre 2, une bonne conception est une conception qui minimise la 
rigidite, la fragilite, l'immobilite et l'inverifiabilite d'une application. 

L'ideal pour une modelisation logicielle est d'aboutir a une separation totale entre les 
differentes preoccupations d'une application afin que chacune d'elles puisse evoluer sans 
impacter les autres, perennisant ainsi au maximum le code de l'application. 

Typiquement, une application recele deux sortes de preoccupations : les preoccupations 
d'ordre fonctionnel et les preoccupations d'ordre technique. Une separation claire entre 
ces deux types de preoccupations est souhaitable a plus d'un titre : le code metier est 
ainsi perennise par rapport aux evolutions de la technique, les equipes de developpement 
peuvent etre specialisees (equipe pour le fonctionnel distincte de l'equipe s'occupant des 
preoccupations techniques), etc. 

Grace a 1' inversion de controle, les conteneurs legers apportent une solution elegante a la 
gestion des dependances et a la creation des objets. lis encouragent la separation claire 
des differentes couches de l'application, aidant ainsi a la separation des preoccupations, 
comme nous avons pu le voir au chapitre 2. 

La modelisation illustree a la figure 2.6, que nous reproduisons ici ( voir figure 4.1) 
montre clairement que les preoccupations d'ordre technique, en l'occurrence la persis- 
tance des donnees centralisee dans les DAO, sont clairement isolees des preoccupations 
fonctionnelles, representees par les classes metier Todo et TodoList ainsi que les classes 
managers. 

Cependant, les conteneurs legers restent de conception orientee objet et souffrent des 
insuffisances de cette approche. Ainsi, la separation des preoccupations techniques et 
fonctionnelles n'est pas toujours etanche. Nous allons montrer que I'approche orientee 
objet ne fournit pas toujours de solution satisfaisante pour aboutir a des programmes 
clairs et elegants. C'est notamment le cas de l'integration des fonctionnalites transversales, 
problematique directement adressee par la POA. 



Integration de fonctionnalites transversales 

Nous qualifions de transversales les fonctionnalites devant etre offertes de maniere simi- 
laire par plusieurs classes d'une application. Parmi les fonctionnalites transversales que 
nous rencontrons souvent dans les applications, citons notamment les suivantes : 

• Securite. L' objet doit s'assurer que l'utilisateur a les droits suffisants pour utiliser ses 
services ou manipuler certaines donnees. 

• Integrite referentielle. L' objet doit s'assurer que ses relations avec les autres sont 
coherentes par rapport aux specifications du modele metier. 

• Gestion des transactions. L' objet doit interagir avec le contexte transactionnel en 
fonction de son etat (valide : la transaction continue ; invalide : la transaction est inva- 
lided, et les effets des differentes operations sont annules). 
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Figure 4.1 
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Avec l'approche orientee objet, ces fonctionnalites sont implementees dans chaque 
classe concernee, au moins sous forme d'appels a une bibliofheque ou un framework 
specialises. Une evolution de ces fonctionnalites transversales implique la modification 
de plusieurs classes. Par ailleurs, nous pouvons constater que ces fonctionnalites trans- 
versales sont des preoccupations en elles-memes. Le fait qu'elles soient prises en charge 
par des classes destinees a repondre a d'autres preoccupations n'est done pas satisfaisant. 



Exemple de fonctionnalite transversale dans Tudu Lists 

Pour mieux apprehender ce probleme, imaginons que nous desirions faire evoluer Tudu 
Lists de telle sorte que 1' application supporte le declenchement de traitements en fonc- 
tion d'evenements techniques. L'idee est de permettre a des objets de s'inscrire aupres 
d'un DAO afin de reagir en fonction des appels a ses methodes. Ainsi, il sera possible de 
creer des objets enregistrant ces evenements a des fins statistiques, par exemple. 

Cette fonctionnalite transversale concerne les interfaces DAO de notre modele metier 
simplified a savoir TodoDAO et TodoListDAO, ainsi que leurs implementations. L'approche 
par les modeles de conception apporte une solution generique eprouvee sous la forme du 
design pattern observateur. 

Le design pattern observateur permet a un objet de signaler un changement de son etat a 
d'autres objets, appeles observateurs. Ce design pattern est simple a implementer avec 
Java puisque l'API standard de J2SE fournit une interface (java.util .Observer) et une 
classe (java.util .Observable) offrant la base necessaire. 

L'interface Observer doit etre implementee par les classes des observateurs. Cette inter- 
face ne comprend qu'une seule mefhode, update, qui est appelee pour notifier l'observa- 
teur d'un changement au niveau du sujet d'observation. 

La classe Observabl e doit etre utilisee par la classe observee. Cette classe fournit la meca- 
nique d'inscription et de desinscription des observateurs (methodes addObserver et 
del eteObserver) ainsi que la mecanique de notification (methodes noti fyObservers). 

L'utilisation d'Observable par la classe observee peut se faire de deux manieres differen- 
tes. La premiere revient a employer l'heritage, avec toutes les contraintes que cela 
impose (impossibilite d'heriter d'autres classes). La seconde consiste a creer une classe 
interne heritant d'Observable. Cette derniere nous semble la meilleure en ce qu'elle offre 
davantage de flexibilite dans le cas oil la classe observee comporte plusieurs sujets 
d'observation - il suffit de creer un attribut d'un type derivant d'Observabl e par sujet - et 
permet de mieux isoler la logique du design pattern du reste de la classe. 

La figure 4.2 illustre sous forme de schema UML la mise en ceuvre de ce design pattern 
avec l'API Java. 

II est aussi possible d'utiliser la publication d'evenements proposee par le contexte 
d' application de Spring, mais cette publication est davantage adaptee aux evenements 
impactant l'ensemble de l'application (rafraichissement de contexte par exemple) qu'aux 
evenements dont la granularite est fine. 



Les concepts de la POA 



Chapitre 4 



Figure 4.2 

Utilisation du design 
pattern observateur en Java 



Observe 



java.util. Observable 



SujetObservation 



~7K — 7j\ — 7J\~ 

! «utilise» I 
I 1 

«utilise» I • I «utilise» 

1 ! L 

I I I 

I 



I 

Observateur! Observateur2 



I 

ObservateuKJ 



«interface» 
java.util. Observer 



L' implementation generique du design pattern observateur etant definie, nous allons 
l'appliquer pour developper notre fonctionnalite transversale et analyser ses effets sur la 
qualite de conception de Tudu Lists. 

Implementation du design pattern observateur dans Tudu Lists 

Les evenements fonctionnels susceptibles de nous interesser correspondent aux methodes 
de nos managers. Pour simplifier l'expose, nous ne fournissons ici que 1' implementation 
du design pattern observateur pour TodoDAO et TodoDAOHibernte, sachant que le principe 
reste le meme pour TodoListDAO et TodoListDAOHibernate. 

Nous pouvons definir la correspondance entre les methodes de l'interface TodoDAO et les 
evenements fonctionnels associes de la maniere suivante : 

• saveTodo : evenement « enregistrement d'un todo » ; 

• removeTodo : evenement « suppression d'un todo ». 
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Nous avons volontairement ecarte la fonction getTodo, car elle est utilisee en consultation 
et genererait un nombre tres important d'evenements sans qu'ils aient un interet fonctionnel 
evident, a la difference des autres evenements. 

Afin de profiter des avantages du conteneur leger de Spring pour la configuration des 
objets et la gestion des dependances, le design pattern observateur a ete implements de 
maniere legerement differente que le modele generique presente en debut de chapitre, 
comme le montre le diagramme UML illustre a la figure 4.3. 
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Figure 4.3 

Implementation du design pattern observateur dans Tudu Lists 



Pour ameliorer la lisibilite de cette figure, nous n' avons pas mentionne l'ensemble des 
methodes de TodoDAO et TodoDAOHibernate. Seules sont representees celles qui doivent etre 
specialement creees pour implementer les sujets d'observation. 
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Pour implementer les sujets d'observation, nous avons cree la notion d'evenement, repre- 
sentee par l'interface Event, conformement a l'esprit de Spring, qui separe interfaces et 
implementations. Un evenement dispose d'un attribut type de type String pouvant pren- 
dre deux valeurs, SaveTodoEvent et RemoveTodoEvent, representant chacune un des evenements 
que nous avons mentionne en debut de section. 

Un evenement dispose de trois methodes servant d' abstraction a la classe 
java.util .Observable : addListener et setLi steners, pour inscrire les observateurs du 
sujet d'observation, et fireEvent, pour avertir les observateurs que l'evenement observe 
s'est realise. 

Le code de l'interface Event est le suivant : 
package tudu. service. events; 

import java.util .Observer; 

public interface Event { 

String getType( ) ; 

void f i reEvent( ) ; 

void addl_istener(Observer obs); 

} 

L' implementation de cette interface, la classe Eventlmpl, derive de java.util .Observable, 
dont elle utilise les services pour gerer l'inscription des observateurs et leur avertissement 
en cas de changement d'etat. 

Le code de la classe Eventlmpl est le suivant : 

package tudu. service. events. impl ; 

import java.util .Iterator; 

import java.util .Observable; 

import java.util .Observer; 

import java.util .Set; 

import tudu. service. events. Event; 

public class Eventlmpl extends Observable implements Event { 
private String type; 

public void fireEventO { 
super. setChangedt ) ; <- Q 
super. not ifyObservers( ) ; 

} 
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public void addl_istener(Observer obs) { 
super. addObserver(obs) ; 

} 

public void setl_isteners(Set listeners) { 
Iterator i = 1 i steners .i teratort ) ; 
while(i.hasNext()){ 

addObserver( (Observer )i .next( ) ) ; 

} 

} 

public String getTypeO { 
return type; 
} 



public void setType(String type) { 
this. type = type; 

} 

} 

L'appel a la methode setChanged (repere Q) de java.util .Observable est necessaire pour 
que la notification des observateurs fonctionne. Cette methode signale a la classe mere 
qu'un changement d'etat s'est opere dans le sujet d' observation. 

Nous pouvons maintenant faire evoluer l'interface TodoDAO et son implementation Todo- 
DAOHibernate pour prendre en compte cette nouvelle notion d'evenement. Pour cela, nous 
faisons evoluer l'interface TodoDAO en lui ajoutant les fonctions suivantes : 

package tudu. domain. dao; 

import tudu. domain. model .Todo; 
import tudu. service. events. Event; 

public interface TodoDAO { 
(...) 

Event getSaveTodoEventt ) ; 
Event getRemoveTodoEvent( ) ; 

) 

Ces deux methodes permettent de recuperer les differents sujets d'observation correspon- 
dant aux evenements generes par la classe manager. Au niveau de 1' implementation fournie 
par TodoDAOHibernate, cela se materialise par la creation de cinq attributs ainsi que des 
accesseurs et modificateurs associes : 

package tudu. domain. dao. hibernate; 
(...) 

import tudu. service. events. Event; 

public class TodoDAOHibernate implements TodoDAO { 
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(...) 

private Event saveTodoEvent; 
private Event removeTodoEvent; 



public Event getSaveTodoEvent( ) { 
return saveTodoEvent; 

} 

public void setSaveTodoEvent(Event saveTodoEvent) { 
this. saveTodoEvent = saveTodoEvent; 

} 

// Les autres attributs suivent la meme logique 
(...) 

} 

II est necessaire de modifier le code des autres methodes de TodoDAOHibernate afin 
qu'elles appellent la methode f i reEvent de l'evenement qui leur correspond. Le code ci- 
dessous reproduit la modification (en gras dans le code) effectuee pour la methode save- 
Todo : 

public void saveTodotTodo todo) { 

getHibernateTempl ate( ) .saveOrLlpdate(todo) ; 
if (1 ogger .i sDebugEnabledt ) ) { 

logger. debugt "todold set to: " + todo.getTodoIdt ) ) ; 

} 

updateTodoEvent.fi reEvent( ) ; 

} 

Pour removeTodo de la classe TodoDAOHibernate, la logique est exactement la meme. 

Pour initialiser les deux nouveaux attributs, nous utilisons l'injection de dependances 
fournie par Spring. Pour cela, nous definissons dans le fichier WEB-INF/application- 
Context.xml de Tudu Lists deux nouveaux Beans : 

<bean id="saveTodoEvent" 

cl a ss=" tudu. service. events. impl . Event Impl "> 

<property name="type"> 

<val ue>saveTodoEvent</val ue> 

</property> 
</bean> 

<bean id="removeTodoEvent" 

cl a ss=" tudu. service. events. impl .Event Impl "> 

<property name="type"> 

<val ue>removeTodoEvent</val ue> 

</property> 
</bean> 
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Ces Beans sont ensuite injectes dans notre classe TodoDAOHibernate telle que definie dans 
WEB-INF/applicationContext.xml : 

<bean id="todoDA0" 
class="tudu.domain.dao.hibernate.TodoDAOHibernate"> 
(...) 

<property name="saveTodoEvent"> 
<ref local="saveTodoEvent"/> 
</property> 

<property name="removeTodoEvent"> 
<ref 1 ocal ="removeTodoEvent"/> 
</property> 
</bean> 

Nous pouvons maintenant developper un observateur, par exemple une classe chargee de 
calculer des statistiques sur les todos, que nous appelons Stats. Celle-ci se presente de la 
maniere suivante : 

package tudu. domain. model ; 

import java.util .Observable; 
import java.util .Observer; 

import tudu. service. events. Event; 

public class Stats implements Observer { 

public void updatetObservabl e observe. Object args) {<- Q 
if (observe instanceof Event) { 
Event event = (Event) observe; 
String lEventType = event. getType( ) ; 
if ( "SaveTodoEvent" .equal s(l EventType) ) { 

System. out. printlnC'Enregistrement d'un todo"); 
(...) 

} else if ("RemoveTodoEvenf.equalsdEventType)) { 
System. out. printlnCSuppression d'un todo"); 
(...) 

} 

} 

} 

} 

Pour inscrire cet observateur aupres des sujets d'observation, nous le ferons injecter par 
le conteneur dans les evenements via leur methode setListeners : 

<bean id="stats" class="tudu. domain. model .Stats"/> 



<bean id="saveTodoEvent" 
class=" tudu. service. event s.impl . Event Impl "> 
<property name="type"> 

<val ue>saveTodoEvent</val ue> 
</property> 



Les concepts de la POA 



Chapitre 4 



<property name="l i steners"> 
<set> 

<ref 1 ocal ="stats"/> 
</set> 
</property> 
</bean> 



<bean id="removeTodoEvent" 
class="tudu. service. events. impl . Event Impl "> 
<property name="type"> 

<val ue>removeTodoEvent</val ue> 
</property> 

<property name="l isteners"> 
<set> 

<ref local="stats"/> 
</set> 
</property> 
</bean> 

Lorsqu'un evenement est genere (via l'appel a la methode f1 reEvent), la methode update 
est appelee (repere Q). 

Si nous executons maintenant 1' application, nous constatons qu'en manipulant des todos, 
nous generons des evenements affiches dans la console. 

Critique de ('implementation orientee objet 

L' implementation du design pattern observateur n'est guere compliquee, quoiqu'un peu 
fastidieuse. Si nous nous interessons a la qualite de la conception, nous nous apercevons 
que celle-ci n'est pas totalement satisfaisante, bien qu'elle respecte l'etat de l'art en 
terme de conception orientee objet. 

Le probleme conceptuel reside dans la modelisation des sujets d'observation. Ideale- 
ment, l'observation devrait etre transparente pour la classe observee, c'est-a-dire qu'elle 
ne devrait pas avoir a gerer le fait d'etre observee. L'observation du comportement d'une 
classe au travers de l'appel de ses methodes est une problematique transversale (nous 
pourrions, par exemple, vouloir observer de la meme facon I'implementation TodoListDAO). 
Or, comme nous pouvons le constater en analysant I'implementation orientee objet que 
nous venons de fournir, toute nouvelle classe observee necessite une nouvelle implemen- 
tation des sujets d'observation, alors meme qu'ils suivent le meme principe generique. 

Par ailleurs, le moment oil sont notifies les observateurs est defini en dur dans le code de 
la classe observee. Si nous desirons changer ce moment, par exemple, en notifiant avant 
un traitement plutot qu'apres, il est necessaire de modifier directement la classe. 

Enfin, l'ajout de nouveaux sujets d'observation a une classe observee implique une plus 
grande complexite de son code. Une classe simple ayant beaucoup de sujets d'observa- 
tion differents, par exemple, peut voir une partie non negligeable de son code vouee aux 
sujets d'observation. 
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Si nous reprenons nos cinq criteres d'analyse d'une conception, nous constatons une 
degradation de la qualite de la modelisation : 

• Le modele est devenu plus rigide et fragile, car la generation d'evenements est 
etroitement liee au code de chaque methode observee. II faut done veiller qu'une 
modification de ce code n'entraine pas de dysfonctionnement de la generation des 
evenements (suppression malencontreuse de l'appel a la methode fireEvent, par 
exemple). 

• L'immobilite du modele est augmentee puisque 1' observation devient partie integrante 
du DAO. Si nous desirons faire une version de Tudu Lists sans sujet d' observation, 
nous sommes contraints de conserver la mecanique d' observation, sauf a la supprimer 
directement dans le code. 

• La verification du fonctionnement du DAO est rendue plus difficile, augmentant 
d'autant l'inverifiabilite du modele, dans la mesure oil il est necessaire de prendre en 
compte dans les tests les sujets d' observation, en fournissant des simulacres, par 
exemple (voir le chapitre 17 consacre aux tests). 

Alors que la separation des interfaces et des implementations couplee avec l'injection de 
dependances a pour objectif de rendre les classes les plus independantes possible, nous 
constatons que le design pattern observateur n'est pas correctement modularise et genere 
un phenomene de dispersion du code au fur et a mesure de son utilisation pour differentes 
classes de Tudu Lists. 

Analyse du phenomene de dispersion 

Partant d'un tel constat, il est legitime de se demander si une meilleure conception et 
un autre decoupage des classes de l'application ne permettraient pas de faire dis- 
paraitre cette dispersion du code. La reponse est malheureusement le plus souvent 
negative. 

La raison qui tend a prouver que la dispersion du code est ineluctable est liee a la diffe- 
rence entre service offert et service utilise. Une classe fournit, via ses methodes, un ou 
plusieurs services. II est aise de rassembler tous les services fournis dans un meme 
endroit, e'est-a-dire dans une meme classe. Cependant, rien dans l'approche objet ne 
permet de rassembler les utilisations de ce service. II n'est done pas surprenant qu'un 
service general et d'utilisation courante soit utilise partout. 

La dispersion d'une fonctionnalite dans une application est un frein a son developpe- 
ment, a sa maintenance et a son evolutivite. Lorsque plusieurs fonctionnalites sont 
dispersees, la situation empire. Le code ressemble alors a un plat de spaghettis, avec de 
multiples appels a diverses API. II devient embrouille (en anglais tangled). Ce pheno- 
mene se manifeste dans de nombreuses applications. 

II devient done evident qu'une nouvelle dimension de modularisation doit etre creee afin 
de capturer les fonctionnalites transversales au sein d'entites specifiques preservant la 
flexibilite de la conception de l'application. 
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En resume 

L'approche orientee objet a apporte un niveau de modularisation important grace a la 
notion d'objet et aux mecanismes associes (heritage, polymorphisme, etc.). Cependant, 
cette approche est grevee de limitations fondamentales, qui apparaissent des qu'il s'agit 
de modulariser des preoccupations transversales d'une application. Celles-ci sont gene- 
ralement dispersees au sein du code, rendant leur maintenance et leur evolution delicates. 

La POA introduit de nouvelles notions offrant une dimension supplementaire de modula- 
risation adaptee a ces problematiques. 

Notions de base de la POA 

Pour repondre au besoin de modularisation des fonctionnalites transversales, la POA a 
introduit de nouvelles notions, qui viennent en complement de celles de l'approche objet. 

Dans cette section, nous presentons ces nouvelles notions en montrant comment elles 
interviennent pour ameliorer l'integration de fonctionnalites transversales, comme le 
design pattern observateur. 

Outre la notion d' aspect, equivalent de la notion de classe en POO, nous detaillons les 
notions de point de jonction, de coupe, de greffon, aussi appele code advice, et d' intro- 
duction, qui sont au coeur de la notion d' aspect, au meme titre que les attributs ou les 
methodes le sont pour la notion de classe. 

La notion d'aspect 

Pour apprehender la complexite d'un programme, nous cherchons generalement a le 
decouper en sous-programmes de taille moins importante. Les criteres a appliquer pour 
arriver a cette separation ont fait l'objet de nombreuses etudes, visant a faciliter la 
conception, le developpement, la maintenance et l'evolutivite des programmes. 

La programmation procedurale induit un decoupage en fonction des traitements a imple- 
menter, tandis que la programmation objet induit un decoupage en fonction des donnees 
qui seront encapsulees dans les classes avec les traitements associes. Comme nous 
l'avons vu, certaines fonctionnalites s'accommodent mal de ce decoupage, et les instruc- 
tions correspondant a leur utilisation se retrouvent dispersees dans 1' ensemble de 1' appli- 
cation. Tout changement dans 1' utilisation de ces fonctionnalites implique de devoir 
consulter et modifier un grand nombre de fichiers. 

L'apport essentiel de la POA est de fournir un moyen de rassembler dans une nouvelle 
entite, 1' aspect, le code d'une fonctionnalite transversale, habituellement disperse au sein 
de l'application avec les approches classiques de programmation. 



Aspect 

Entite logicielle qui capture une fonctionnalite transversale a une application. 
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La definition d'un aspect est presque aussi generale que celle d'une classe. Une classe est 
un element du probleme a modeliser (la clientele, les commandes, les fournisseurs, etc.), 
auquel nous associons des donnees et des traitements. De meme, un aspect est une fonc- 
tionnalite a mettre en oeuvre dans une application (la securite, la persistance, etc.), dont 
1' implementation comprendra les donnees et les traitements relatifs a cette fonction- 
nalite. 

En POA, une application comporte des classes et des aspects. Un aspect se differencie 
d'une classe par le fait qu'il implemente une fonctionnalite transversale a 1' application, 
c'est-a-dire une fonctionnalite qui, en programmation orientee objet ou procedurale, 
serait dispersee dans le code de cette application. 

La presence de classes et d' aspects dans une meme application introduit done deux 
dimensions de modularite : celle des fonctionnalites implementees par les classes et 
celles des fonctionnalites transversales, implementees par les aspects. 

La figure 4.4 illustre l'effet d'un aspect sur le code d'une application. La partie gauche de 
la figure schematise une application composee de trois classes. Les filets horizontaux 
representent les lignes de code correspondant a une fonctionnalite, par exemple, la 
gestion des traces. Cette fonctionnalite est transversale a 1' application, car elle affecte 
toutes ses classes. La partie droite de la figure montre la meme application apres ajout 
d'un aspect de gestion des traces (rectangle noir). Le code de cette fonctionnalite est 
maintenant entierement localise dans 1' aspect, et les classes sont vierges de toute intru- 
sion. Une application ainsi concue avec un aspect est plus simple a ecrire, maintenir et 
faire evoluer qu'une application sans aspect. 




Sans aspect 



Figure 4.4 

Impact d'un aspect sur la localisation d'une fonctionnalite transversale 



Avec aspect 
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Dans notre exemple d' implementation du design pattern observateur, l'utilisation d'un 
aspect permet de laisser inchange le code des classes observees (interface et implementa- 
tion, en l'occurrence TodoDAO et TodoDAOHibernate). Par ailleurs, les observateurs ne sont 
plus lies a la classe manager, mais directement a 1' aspect. 

Le diagramme de classes illustre a la figure 4.5 montre les effets de la modularisation de 
1' implementation du design pattern observateur dans Tudu Lists. 
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Figure 4.5 

Modelisation du design pattern observateur sous forme d 'aspect dans Tudu Lists 



Grace a cette nouvelle dimension de modularisation, la separation des preoccupations 
est maintenue, avec un modele metier qui conserve son expressivite originelle et sur 
lequel s'interfacent des extensions clairement identifiees apportees par 1' aspect. Ces 
extensions, transparentes pour les managers - notons l'inversion de controle au profit 
de 1' aspect -, permettent une reutilisation de la fonctionnalite transversale sans 
dispersion du code. 

Nous verrons dans la suite de ce chapitre que deux elements entrent dans l'ecriture 
d'un aspect, la coupe et le greffon, ou code advice. La coupe definit le caractere trans- 
versal de 1' aspect, c'est-a-dire les endroits de 1' application dans lesquels la fonctionna- 
lite transversale doit s'integrer, tandis que le greffon fournit le code proprement dit de 
cette derniere. 
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Les points de jonction 

Nous avons vu qu'un aspect etait une entite logicielle implementant une fonctionnalite 
transversale a une application. La definition de cette structure transversale passe par la 
notion de point de jonction. 



Point de jonction (join point) 

Point dans I'execution d'un programme autour duquel un ou plusieurs aspects peuvent etre ajoutes. 



Nous verrons a la section suivante qu'il existe differents types de points de jonction. II 
peut s'agir, par exemple, de points dans I'execution d'un programme oil une methode est 
appelee. 

La notion de point de jonction est tres generale. Elle peut etre comparee a celle de point 
d'arret d'execution, qui, lors de la mise au point d'un programme a l'aide d'un debo- 
gueur, designe un endroit du code source oil nous souhaitons voir I'execution s'arreter. 
Dans le cadre de la POA, un point de jonction designe un endroit du programme oil nous 
souhaitons ajouter un aspect. L'analogie s'arrete la. L' emplacement du point d'arret est 
fourni de facon interactive par le developpeur via un numero de ligne dans le code 
source. En POA, le point de jonction est fourni de maniere « programmatique » par le 
developpeur. 

Si, en theorie, rien n'empeche d'utiliser les numeros de ligne du code source pour definir 
un point de jonction, aucun des outils de POA existants ne le permet. Le coflt a payer, en 
terme de perte de performance a I'execution et de complexite d' implementation de 
l'outil, est juge prohibitif. De surcroit, la moindre modification dans les numeros de ligne 
du code source imposerait une mise a jour coflteuse de la definition des points de 
jonction. 

Les differents types de points de jonction 

En faisant reference a I'execution d'un programme, la notion de point de jonction revele 
son caractere eminemment dynamique. II s'agit d'evenements qui surviennent une fois 
le programme lance. Lorsqu'il s'agit de definir concretement et de maniere 
« programmatique » un point de jonction, il est necessaire de s'appuyer sur la structure 
des programmes. Dans 80 % des cas, nous nous appuyons sur des methodes. 

Dans notre implementation du design pattern observateur, les points de jonction a utiliser 
pour l'aspect d'observation sont les appels aux differentes methodes de TodosManager 
auxquels correspondent nos evenements. 

Les methodes ne sont pas les seuls elements qui structurent les programmes orientes 
objet. Classes, interfaces, exceptions, attributs, blocs de code et instructions (for, while, 
if, switch, etc.) en font egalement partie. Avec Spring AOP, un seul point de jonction 
existe (execution de methodes) en standard. Cependant, d'autres outils de POA, comme 
AspectJ, JAC ou JBoss AOP, supportent d'autres points de jonction, comme les attributs, 
ou plus exactement leurs acces en lecture ou en ecriture. 
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Aussi simple soit-il, un programme comporte de nombreux points de jonction potentiels. 
La tache du programmeur d' aspects consiste a selectionner les points de jonction perti- 
nents pour son aspect. La section suivante s'interesse a la facon dont s'opere cette selection. 
Celle-ci passe par la notion de coupe. 

Les coupes 

Nous avons vu que les points de jonction etaient des elements lies a 1' execution d'un 
programme, autour desquels nous souhaitons greffer un aspect. En ce qui concerne 
l'ecriture du code de l'aspect, il est necessaire de disposer d'un moyen pour designer de 
maniere concrete les points de jonction a prendre en compte. Ce moyen est fourni par la 
coupe. 



Coupe (crosscut) 

Designe un ensemble de points de jonction. 



Une coupe est definie a l'interieur d'un aspect. Dans les cas simples, une seule coupe 
suffit pour definir la structure transversale d'un aspect. Dans les cas plus complexes, un 
aspect est associe a plusieurs coupes. 

Les notions de coupes et de points de jonction sont liees par leur definition. Pourtant, leur 
nature est tres differente. Une coupe est un element de code defini dans un aspect, alors 
qu'un point de jonction est un point dans 1' execution d'un programme. Si une coupe 
designe un ensemble de points de jonction, un point de jonction donne peut appartenir a 
plusieurs coupes d'un meme aspect ou d'aspects differents. Dans ce cas, comme nous le 
verrons dans la suite de ce chapitre, il est necessaire de definir l'ordre d' application des 
differentes coupes et des differents aspects autour des points de jonction. 

Avec Spring AOP, la definition des coupes repose sur l'utilisation de deux operateurs 
ensemblistes, l'union et l'intersection. Dans la majorite des cas, c'est l'union qui est utili- 
sed pour lier les differents points de jonction composant la coupe. C'est notamment le cas 
pour notre exemple d' implementation du design pattern observateur, oil nous avons cinq 
points de jonction (un par methode observee de TodoDAO) qui doivent etre pris en compte 
par notre aspect. 

Les greffons 

Nous avons vu qu'une coupe definissait oil un aspect devait etre greffe dans une applica- 
tion. La coupe designe pour cela un ensemble de points de jonction. Le greffon, ou code 
advice, definit quant a lui ce que l'aspect greffe dans l'application, autrement dit les 
instructions ajoutees par l'aspect. 



Greffon (code advice) 

Bloc de code definissant le comportement d'un aspect. 
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Un aspect comporte un ou plusieurs greffons. Chaque greffon definit un comportement 
particulier pour son aspect. Le greffon joue en quelque sorte le meme role qu'une 
methode. A la difference des methodes, cependant, les greffons sont associes a une 
coupe, et done a des points de jonction, et ont un type. D'un point de vue plus abstrait, il 
convient de noter que si une methode definit une fonctionnalite a part entiere, un greffon 
definit plutot 1' integration d'une fonctionnalite a priori transversale. 

Chaque greffon est associe a une coupe. La coupe fournit l'ensemble des points de jonc- 
tion autour desquels sera greffe le bloc de code du greffon. Une meme coupe peut etre 
utilisee par plusieurs greffons. Dans ce cas, differents traitements sont a greffer autour 
des memes points de jonction. Cette situation pose le probleme de la composition 
d' aspect, que nous n'abordons pas ici. 

Pour notre exemple, le greffon se reduit a l'equivalent de l'appel de la methode fire- 
Event, realise precedemment directement dans le code de TodoDAOHibernate. Les attributs 
saveTodoEvent et removeTodoEvent sont bien entendu deplaces dans l'aspect, qui est, dans 
le cas de Spring AOP, une classe Java. 

Les differents types de greffon 

Avec Spring, il existe quatre types de greffons, qui se differencient par la facon dont le 
bloc de code est execute lorsqu'un point de jonction de la coupe a laquelle ils sont asso- 
cies apparait : 

• before : le code est execute avant les points de jonction, e'est-a-dire avant l'execution 
des methodes. 

• after returning : le code est execute apres les points de jonction, e'est-a-dire apres 
l'execution des methodes. 

• after throwing : le code est execute apres les points de jonction si une exception a ete 
generee. 

• around : le code est execute avant et apres les points de jonction. 

Dans le cas des greffons around, il est necessaire de delimiter la partie de code qui doit 
etre executee avant le point de jonction et celle qui doit l'etre apres. Les outils de POA 
fournissent pour cela une instruction ou une methode speciale, nommee proceed (proce- 
der, continuer). La methode proceed permet de revenir a l'execution du programme, 
autrement dit d'executer le point de jonction. 

Le deroulement d'un programme avec un greffon around peut etre resume de la facon 
suivante : 

1 . Execution normale du programme. 

2. Juste avant un point de jonction appartenant a la coupe, execution de la partie avant 
du greffon. 
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3. Appel a proceed. Cela declenche l'execution du code correspondant au point de 
jonction. 

4. Execution de la partie apres du greffon. 

5. Reprise de l'execution du programme juste apres le point de jonction. 

L' appel a proceed est facultatif, un code advice around pouvant parfaitement ne jamais 
appeler proceed. Dans ce cas, le code correspondant au point de jonction n'est pas 
execute, et le bloc du greffon remplace le point de jonction. Apres l'execution du greffon, 
le programme reprend son execution juste apres le point de jonction. 

Un greffon around peut aussi appeler proceed dans certaines situations et pas dans 
d'autres. C'est le cas, par exemple, d'un aspect de securite qui controle l'acces a une 
methode. Si l'utilisateur est correctement authentifie, l'appel de la methode est autorise, 
et l'aspect invoque proceed. Si l'utilisateur n'a pas les bons droits, l'aspect de securite 
n'invoque pas proceed, ce qui a pour effet de ne pas executer le point de jonction et done 
de ne pas appeler la methode. 

Dans certains cas, proceed peut etre appele plusieurs fois. Cela peut s'averer utile pour 
des aspects qui ont a faire plusieurs tentatives d'execution du point de jonction, suite, par 
exemple, a des pannes ou a des erreurs d'execution. 

L'instruction proceed ne concerne pas les greffons before et after. Par definition, un code 
advice before n'a qu'une partie avant. II n'y a done pas de partie apres a delimiter. Un 
code advice before est automatiquement greffe avant le point de jonction. II en va de 
meme des codes advice after, qui n'ont qu'une partie apres. 

Notons que le type around est l'union des types before et after. II est done tentant de 
n'utiliser que le type around, puisqu'il est en mesure d'offrir les memes services que 
before et after. Nous deconseillons toutefois fortement cette pratique, car cela nuit a la 
bonne comprehension du role et des effets du greffon dans 1' application. 

Dans notre exemple, le type de greffon a utiliser est after returning. En effet, l'utilisa- 
tion du type around est trop generique pour notre besoin. Quant a l'utilisation du type 
before, elle s'avere risquee puisque la methode peut ne pas realiser l'operation observee, 
par exemple en generant une exception. 

Le mecanisme d' introduction 

Les mecanismes de coupe et de greffon que nous avons vus jusqu'a present permettent de 
definir des aspects qui etendent le comportement d'une application. Les coupes desi- 
gnent des points de jonction dans l'execution de l'application, tandis que les greffons 
ajoutent du code avant ou apres ces points. 

Dans tous les cas, il est necessaire que les codes correspondant aux points de jonction 
soient executes pour que les greffons le soient egalement. Si les points de jonction n'appa- 
raissent jamais, les greffons ne sont jamais executes, et l'aspect n'a aucun effet sur 
l'application. 
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Le mecanisme d' introduction permet d'etendre le comportement d'une classe en modi- 
fiant sa structure, c'est-a-dire en lui ajoutant des elements, essentiellement des attributs 
ou des methodes. Dans le cas de Spring AOP, nous ne pouvons introduire que de 
nouvelles interfaces avec 1' implementation associee. Ces changements structurels sont 
visibles des autres classes, et celles-ci peuvent les utiliser au meme titre que les elements 
originels de la classe. Contrairement aux greffons, qui etendent le comportement d'une 
application si et seulement si certains points de jonction sont executes, le mecanisme 
d' introduction est sans condition, et l'extension est realisee dans tous les cas. Le terme 
introduction renvoie au fait que ces elements sont introduits, c'est-a-dire ajoutes a la 
classe. 

Comme le mecanisme d'heritage des langages de programmation orientee objet, le 
mecanisme d' introduction de la POA permet d'etendre une classe. Neanmoins, contraire- 
ment a l'heritage, l'introduction ne permet pas de redefinir une methode. L' introduction 
est done un mecanisme purement additif, qui ajoute de nouveaux elements a une classe. 

Dans notre exemple, nous pouvons transformer une classe quelconque de Tudu Lists en 
observateur. En effet, grace au mecanisme d' introduction, nous pouvons lui faire imple- 
menter l'interface java.util .Observer sans modifier son code source. L implementation 
de la methode update de cette interface est assuree au sein de l'aspect par un greffon d'un 
type particulier, appele mix-in. 



Le tissage d'aspect 

Une application utilisant la POA est composee d'un ensemble de classes et de un ou 
plusieurs aspects. Une operation automatique est necessaire pour obtenir une application 
operationnelle, integrant les fonctionnalites des classes et celles des aspects. 

Cette operation est designee sous le terme de tissage (en anglais weaving). Le programme 
qui la realise est un tisseur d'aspects (en anglais aspect weaver). L'application obtenue a 
l'issue du tissage est dite tissee. 



Tisseur d'aspects (aspect weaver) 

Programme qui realise une operation d'integration entre un ensemble de classes et un ensemble 
d'aspects. 



L operation de tissage peut etre effectuee a la compilation ou a l'execution. Dans le cas 
de Spring AOP, le tissage s'effectue uniquement a l'execution, au sein du conteneur 
leger. Le conteneur leger controlant l'instanciation des classes de l'application, il est en 
mesure de declencher le tissage des aspects si necessaire. Bien entendu, lorsqu'une 
classe est directement instanciee dans l'application, sans passer par le conteneur leger, le 
tissage ne peut s'effectuer. 

Le tissage effectue par Spring AOP repose sur l'utilisation de proxy dynamiques 
crees avec l'API standard J2SE (voir la classe java.lang. reflect. Proxy). Ces proxy 
dynamiques interceptent les appels aux methodes de l'interface, appellent les greffons 



Les concepts de la POA 



Chapitre 4 



implemented par les aspects et redirigent, en fonction du type de greffon, les appels a la 
classe implementant 1' interface. 

Pour illustrer ce mode de fonctionnement, supposons que nous ayons une interface appe- 
lee Unelnterface, une classe appelee Unelmpl implementant cette interface et un aspect 
dont la coupe porte sur l'appel a la methode uneMethode de Unelnterface. 

Lors de l'injection des dependances, au lieu de renvoyer directement une instance de 
Unelmpl, le conteneur leger genere un proxy dynamique de l'interface Unelnterface. Ce 
proxy dynamique intercepte les appels a l'ensemble des methodes definies dans Uneln- 
terface. Quand uneMethode est appelee, le proxy execute le greffon associe a la coupe. Si 
le greffon est de type before, il est execute en premier, puis l'appel est redirige vers 
Unelmpl. Si le greffon est de type after, l'appel est redirige vers Unelmpl, puis le greffon 
est execute. Si le greffon est de type around, seul le greffon est appele par le proxy, charge 
au premier de rediriger l'appel a Unelmpl via l'instruction proceed. 

L'utilisation de proxy dynamiques par le biais de l'API J2SE ne fonctionne qu'avec des 
interfaces. Pour effectuer un tissage sur une classe sans interface, Spring AOP utilise la 
bibliotheque open source CGLIB (Code Generation Library) pour generer le proxy. 

Grace a son mode de fonctionnement, Spring AOP peut etre utilise sans difficulte au sein 
d'un serveur d' applications, ce qui n'est pas toujours le cas des autres outils de POA 
effectuant un tissage a l'execution. Du fait de leur fonctionnement en dehors d'un conte- 
neur leger, ils ont besoin de controler le chargeur de classes pour effectuer le tissage 
a l'execution. Malheureusement, cette operation n'est pas toujours possible avec les 
serveurs d' applications. 



Utilisation de la POA 

Comme tout nouveau paradigme de programmation, la POA necessite un temps 
d'apprentissage non negligeable avant de pouvoir etre utilisee de maniere efficace. Elle 
ne beneficie pas encore d'assez de retours d' experience pour etre employee de maniere 
generalisee dans les projets. Par ailleurs, les outils de POA ne jouissent pas d'un support 
pousse dans les environnements de developpement, a 1' exception notable d'AspectJ, 
l'outil pionnier de la POA, ce qui ne facilite pas le travail des developpeurs, notamment 
dans la mise au point des programmes. 

Spring AOP, non content de fournir une implementation des concepts fondamentaux de 
la POA, propose un certain nombre d' aspects prets a l'emploi. Dans le package 
org. springf ramework.aop. interceptor, nous disposons d'aspects de debogage, de trace et 
de monitoring de performance. Dans le package org. springf ramework. transaction. inter- 
ceptor, nous trouvons 1' implementation en POA de la gestion des transactions. Enfin, 
dans le package org . spri ngf ramework . orm. hi bernate3, un aspect de gestion des sessions Hiber- 
nate est propose comme solution de rechange a l'approche par callback du template 
Hibernate fourni par Spring. 

Pour une initiation a l'utilisation de la POA dans des projets, nous recommandons de 
commencer par ces aspects, qui ont fait leurs preuves. Nous aurons l'occasion de les 
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aborder plus en detail au fil de cet ouvrage. Pour aller plus loin et developper de 
nouveaux aspects, nous conseillons de commencer par des problematiques simples, sans 
impact direct sur la perennite de 1' application, comme 1' implementation d'un systeme de 
conception par contrat. 

II est aussi possible d'implementer simplement certains design patterns en POA, avec a la 
cle de reels benefices. Outre le design pattern observateur, citons notamment les modeles 
de conception commande, chaine de responsabilite et proxy. L' ouvrage Progr -animation 
orientee aspect pour Java/J2EE en fournit des implementations pour AspectJ, mais elles 
sont aisement transposables avec Spring AOP 

En resume 

La POA introduit de nouvelles notions, telles que aspect, point de jonction, coupe, gref- 
fon et introduction, qui permettent de modulariser correctement les fonctionnalites trans- 
versales au sein d'entites specifiques, les aspects. Ces notions viennent en complement 
de celles de l'approche orientee objet mais ne les remplacent pas. 

Au final, cette nouvelle dimension de modularisation apporte un degre d'inversion de 
controle supplementaire, puisqu'elle decharge les classes de 1' implementation de la fonc- 
tionnalite au profit d'entites exterieures, en l'occurrence les aspects. 

Conclusion 

Nous avons vu que l'approche orientee objet, meme dotee de concepts pousses, comme 
ceux des conteneurs legers, n'apportait pas de solution satisfaisante a 1' integration de fonc- 
tionnalites transversales. Ces fonctionnalites rendent le code moins flexible et genent la 
separation claire des preoccupations du fait du phenomene de dispersion. La POA repond 
de maniere elegante a ces problematiques en introduisant le concept fondamental d' aspect, 
complementaire de ceux utilises par les langages de programmation orientes objet. 

Spring AOP fournit une implementation plus limitee de la POA que des outils tels 
qu'AspectJ (dont il integre cependant une partie des fonctionnalites) mais offre suffisam- 
ment de fonctionnalites dans son tisseur a l'execution pour repondre a la plupart des 
besoins de modularisation sous forme d' aspects. Des fonctionnalites majeures de Spring 
sont d'ailleurs implementees avec Spring AOP, comme la gestion des transactions (voir 
le chapitre 12). 

Spring AOP supporte les aspects crees avec AspectJ dans le conteneur leger afin de 
repondre aux besoins complexes en POA ou s'il est necessaire d'operer le tissage a la 
compilation. L'un des grands avantages d' AspectJ est son support par Eclipse, qui le dote, 
via le plug-in AJDT, d' outils facilitant le developpement des aspects. Spring ne fournit 
pas d' integration pour les autres outils de POA que sont JAC et JBoss AOP. 

Nous decrivons en detail Spring AOP au chapitre suivant, dans lequel nous implementons 
sous forme d' aspect le design pattern observateur afin d'illustrer concretement les bene- 
fices apportes par la POA. 
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Le chapitre precedent a rappele les concepts de la POA et montre comment ils permet- 
taient d'ameliorer de maniere significative la qualite d'une application en apportant une 
nouvelle dimension de modularisation. C'est a partir de ces bases conceptuelles que nous 
abordons ici le support de la POA offert par Spring. 

Spring propose un framework 100 % Java, appele Spring AOP, permettant d'utiliser les 
concepts de la POA dans nos applications. Apres le succes d'AspectJ, pionnier en 
matiere de POA, Spring integre depuis sa version 2.0 les fonctionnalites majeures de cet 
outil dans son framework. Cependant, le support de la POA propose par Spring est plus 
limite que celui d'AspectJ en terme de points de jonction pour definir les coupes (Spring 
ne supporte qu'un seul type de point de jonction). En depit de ce support limite, Spring 
AOP couvre la majorite des besoins. 

Spring a la capacite de s'interfacer avec les aspects developpes directement avec AspectJ, 
mais nous n'abordons pas cette possibility dans le cadre de cet ouvrage, l'integration 
partielle d'AspectJ disponible avec Spring AOP se revelant suffisante. 

Les sections qui suivent proposent un tour d' horizon complet de la POA avec Spring et 
detaillent la mise en oeuvre de chaque concept de la POA, tel que aspect, coupe, greffon 
et introduction. 

Implementation de I'aspect observateur avec Spring AOP 

Avant d'aborder 1' implementation de chacun des concepts de la POA avec Spring, nous 
allons entrer dans le vif du sujet en developpant un premier aspect implementant en POA 
le design pattern observateur, que nous avons decrit au chapitre precedent. 

Ce premier aspect nous servira de fil directeur dans le reste du chapitre. 
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Nous avons vu au chapitre precedent que 1' implementation du design pattern observateur 
n'etait pas pleinement satisfaisante en recourant exclusivement a l'approche orientee 
objet. Nous avons alors introduit les concepts de la POA et montre qu'ils permettaient 
d'implementer ce design pattern de maniere non intrusive afin d'assurer une meilleure 
separation des preoccupations au sein de 1' application. 

Pour realiser notre design pattern, nous conservons la majeure partie du code fourni au 
chapitre 4, a savoir l'interface Event et son implementation Eventlmpl. Par contre, les 
developpements realises dans la classe TodoDAO sont maintenant geres sous forme 
d' aspect et doivent done etre reconsideres en utilisant les concepts de la POA. 

Un aspect comprend au minimum une coupe et un greffon. Dans notre exemple, la coupe 
porte sur l'execution des methodes de TodoDAO, tandis que le greffon se reduit a appeler la 
mefhode fireEvent de Eventlmpl. L' inscription prealable des observateurs s'effectue dans 
le fichier de configuration du conteneur leger via la propriete listeners de Eventlmpl 
(materialisee grace au modificateur setListeners). 

Pour l'observateur, nous ne creons qu'une implementation simple, dont le code est repro- 
duit ci-dessous : 

package tudu. aspects. observer; 

import java.util .Observable; 
import java.util .Observer; 

import tudu. event. Event; 

public class DummyObserver implements Observer { 



Comme indique en debut de chapitre, Spring AOP permet de developper un aspect de 
deux manieres : en utilisant le framework AOP de Spring ou en utilisant le support 
d'AspectJ propose par Spring. 

Implementation avec Spring AOP 

Spring AOP etant un framework 100 % Java, done oriente objet, il caique les notions orien- 
tees aspect sur celles orientees objet. Ainsi, pour realiser des greffons, Spring AOP utilise des 
Beans devant implementer une interface specifique en fonction du type de greffon concerne. 

Dans notre exemple, nous devons realiser un greffon de type afterReturning, e'est-a-dire 
qu'un evenement ne sera publie que si le code de la coupe s'execute sans generer 
d'exception. Pour implementer ce type de greffon, Spring AOP dispose de l'interface 




public void update(Observabl e target, Object arg) { 
if(target instanceof Event) { 

System. out. printlnCEvenement detecte ; " 

+( (Event) target) .getType( ) ) ; 
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AfterReturningAdvice, definie dans le package org.springframework.aop, comme les autres 
types de greffons. Cette interface specifie une methode afterReturning, qui est appelee 
pour executer le code du greffon. 

Nous pouvons implementer notre greffon de la maniere suivante : 
package tudu. aspects. observer; 

import java . 1 ang . ref 1 ect .Method ; 

import org.springf ramework. aop. After Ret urningAdvi ce; 

import tudu. service. events. Event; 

public class ObserverAdvice implements AfterReturningAdvice { 

private Event event; 

public Event getEventO { 
return event; 

} 

public void setEventt Event event) { 
this. event = event; 

} 

public void afterReturningtObject returnVal ue. Method method, 

Object[] args, Object target) throws Throwable { 
event.fi reEvent( ) ; 

} 

} 

Notre greffon est un Bean possedant une propriete event, qui est initialisee par le conte- 
neur leger, comme nous le verrons plus loin. Cette propriete implementant toute la logi- 
que de gestion des observateurs, le seul travail de notre greffon est d'appeler sa methode 
fi reEvent. Notons que les parametres de la methode afterReturning permettent d'acceder 
aux informations concernant la methode interceptee (valeur de retour, arguments, etc.). 

La configuration de ce greffon dans le conteneur leger s'effectue de la maniere suivante : 

<bean id="observerAdvice" 

cl ass= "tudu. aspects .observer. Observer Ad vice" > 
<property name="event"> 

<bean class="tudu. service. events. impl .Eventlmpl "> 
<property name="listeners"> 
<set> 

<bean cl ass=" tudu. aspects .observer. Dummy Observe r"/> 
</set> 
</property> 

<property name="type" val ue="execTodoDAO"/> 
</bean> 
</property> 
</bean> 
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Comme nous pouvons le constater, l'evenement associe au greffon est cree sous forme de 
Bean interne. Seul l'observateur DummyObserver que nous avons precedemment defini est 
enregistre aupres de l'evenement. 

Les moments auxquels notre greffon sera execute sont specifies sous forme de coupe. 
Dans notre exemple, ces moments sont les executions des differentes methodes de 
l'interface TodoDAO, a savoir getTodo, saveTodo et removeTodo. Pour definir ces coupes, 
Spring AOP propose differentes classes a utiliser sous forme de Beans geres par le conte- 
neur leger. Ainsi, le framework propose la classe NameMatchMethodPointcut, qui permet de 
definir une coupe sur une liste de noms de fonctions. 

L' utilisation de cette classe donne le resultat suivant dans le fichier de configuration 
applicationContext-springaop.xml du repertoire WEB-INF : 

<bean id="observerPointcut" 
cl ass="org.springf ramework.aop. support. NameMatchMethodPointcut" > 

<property name="mappedNames" val ue="getTodo, saveTodo, removeTodo"/> 

</bean> 

Cette classe dispose d'une propriete mappedNames, qui recoit la liste des noms de methodes 
dont l'execution doit etre interceptee. 

Maintenant que nous avons defini le greffon et la coupe associee, nous pouvons les inte- 
grer au sein d'un aspect. Cette operation s'effectue en utilisant une des classes de Spring 
AOP prevue a cet effet et configurable dans le conteneur leger. 

Pour notre exemple, nous utilisons la classe Defaul tPointcutAdvisor, qui permet d'associer 
un greffon et une coupe : 

<bean id="observerAdvisor" 
cl ass="org.springf ramework.aop. support. Defaul tPointcutAdvisor"> 
<property name="advice" ref="observerAdvice"/> 
<property name="pointcut" ref="observerPointcut"/> 

</bean> 

Cette classe dispose de deux proprietes : advice, contenant la reference au Bean greffon, 
et pointcut, contenant la reference au Bean coupe. 

Pour finir, il est necessaire d'indiquer a Spring AOP de realiser le tissage en instanciant 
un tisseur d'aspect dans le conteneur leger. Ce tissage peut etre manuel ou automatique (a 
partir des informations fournies par les coupes). 

Dans notre exemple, nous realisons un tissage automatique en nous aidant du tisseur 
Defaul tAd visor Auto Proxy Creator : 

<bean class=" 

org.springf ramework.aop. framework. autoproxy . Defaul tAdvisorAutoProxyCreator"/> 
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Grace a ce tisseur, toutes les classes possedant des methodes ayant les noms specifies dans 
la coupe seront interceptees. II faut toutefois prendre garde au perimetre de 1' interception. 
Heureusement, dans Tudu Lists, les noms fournis ne sont utilises que par TodoDAO. 

Si nous lancons 1' application Web et que nous manipulions des todos en creation, modi- 
fication ou suppression, nous constatons sur la console associee au serveur d' applications 
que les messages de notre observateur sont bel et bien affiches. 

Implementation avec le support AspectJ de Spring AOP 

Depuis sa version 2.0, Spring permet d'utiliser certains elements d' AspectJ pour creer 
des aspects sans necessiter l'utilisation directe de cet outil. Cette integration est disponi- 
ble sous deux formes : une forme XML, utilisant un schema specifique, et une forme 
utilisant les annotations Java 5 definies par AspectJ. La premiere forme a l'avantage 
d'etre compatible avec les anciennes versions de Java, tandis que la seconde beneficie de 
la compatibilite avec AspectJ (un aspect defini sous forme d' annotations est directement 
compilable avec AspectJ). 

Pour notre exemple, nous utilisons la premiere forme, la seconde etant abordee ulterieu- 
rement dans ce chapitre. Quelle que soit la forme utilisee, le support d' AspectJ utilise des 
Beans geres dans le conteneur leger pour implementer les differentes notions de la POA. 
Le mapping entre Beans et notions de POA s'effectue au sein du fichier de configuration. 

Contrairement a Spring AOP, le support AspectJ ne necessite pas d' interfaces specifiques 
pour les Beans composant 1' aspect. Notre greffon se code done plus simplement que 
precedemment : 

package tudu. aspects. observer. aspectj ; 

import tudu. service. events. Event; 

public class ObserverAdvice { 
private Event event; 

public Event getEventO { 
return event; 

} 

public void setEvent(Event event) { 
this. event = event; 

} 

public void greffonO { 
event.fi reEvent( ) ; 

} 

} 



Les fondations de Spring 

Partie I 



L' equivalent de la methode afterReturning de l'exemple precedent est la methode gref- 
fon. Notons que cette methode ne possede pas de parametre permettant d'obtenir des 
informations sur la methode ayant ete interceptee par la coupe, contrairement a la 
methode precedente. II s'agit d'un choix d'implementation, et non d'un manque de fonc- 
tionnalites de la part du support d'AspectJ, comme nous le verrons plus loin. 

Le reste de la definition de 1' aspect s'effectue dans le fichier de configuration WEB-INF/ 
EC-aspectj.xml. 

Nous commencons par declarer le schema XML utilise pour la POA (en gras) : 
<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns="http: //www. spri ngframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 

xmlns:aop="http: //www. spri ngframework.org/schema/aop" 
xsi :schemal_ocation=" 

http://www.springframework.org/schema/beans 
http: //www. spri ngf ramework.org/schema/beans/spring-beans .xsd 
http://www.springframework.org/schema/aop 

http://www.springframework.org/schema/aop/spring-aop.xsd"> 

Le schema par defaut etant deja utilise, nous specifions un prefixe pour les tags de la 
POA. Par convention, ce prefixe est aop. 

Comme pour la version Spring AOP pure, nous declarons le Bean correspondant au greffon. 
Sa configuration est identique a la precedente, au package pres : 

<bean id="observerAdvice" 

cl as s="tudu. aspects .observer. aspect j .ObserverAdvice"> 

<property name="event"> 

<bean class="tudu. service. events. impl .Eventlmpl "> 
<property name="l isteners"> 
<set> 

<bean cl ass= "tudu. aspects .observer. DummyObserver"/> 
</set> 
</property> 
</bean> 
</property> 
</bean> 

Nous definissons ensuite 1' aspect grace aux balises dediees a la POA : 
<aop:config> 

<aop:aspect id="observerAspect" ref="observerAdvice"> 
<aop:pointcut id="coupe" 

expression="execution(* tudu.domain.dao.TodoDAO.*( ..))"/> 
<aop:advice 

kind=" after Returning" method^" greffon" 
pointcut-ref=" coupe" /> 
</aop:aspect> 
</aop:config> 
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Le tag aop:conf ig encapsule les definitions d' aspects. Son parametre ref specifie la classe 
contenant le(s) greffon(s) associe(s) a 1' aspect. Un aspect est defini par le tag aop: aspect. 
La coupe est definie par le tag aop:poincut, dont l'attribut expression permet de specifier 
sous forme d'expression reguliere (dans un format specifique d'AspectJ) les methodes a 
intercepter. Ici, il s'agit d'intercepter toutes les executions des methodes de l'interface 
TodoDAO. Nous detaillons plus loin la syntaxe a respecter pour initialiser ce parametre. 

Le parametre i d de la coupe permet de la nommer pour 1' associer a un ou plusieurs greffons. 
Le tag aop: advice permet d' associer le greffon et la coupe. Le parametre kind specifie le 
type du greffon, le parametre method la methode correspondant au greffon et le parametre 
pointcut-ref la reference a la coupe. 

Pour executer cet exemple, nous devons au prealable renommer le fichier application- 
Context-springaop.xml en EC-springaop.xml puis renommer le fichier EC- 
aspectj.xml en applicationContext-aspectj.xml. Ainsi, il n'y aura pas d' interference 
entre les deux aspects que nous venons d' appeler. 

Si nous lancons de nouveau 1' application Web et que nous manipulions des todos en crea- 
tion, modification ou suppression, nous constatons sur la console associee au serveur 
d' applications que les messages de notre observateur sont bel et bien affiches. 

Apres ces premiers pas dans la POA avec Spring, les sections suivantes detaillent les 
fonctionnalites dediees proposees par le framework. Nous commencerons par celles 
offertes par Spring AOP sans support d'AspectJ. En utilisant Spring AOP de cette facon, 
nous pouvons creer des aspects fonctionnant avec les versions 1.2 et 2.0 de Spring. Nous 
verrons ensuite le support d'AspectJ, une nouveaute introduite par la version 2.0 du 
framework. 

Utilisation de Spring AOP sans AspectJ 

Spring supporte la POA depuis sa version 1.0. Ce support se presente sous la forme d'un 
framework 100 % Java implementant les notions de POA sous forme de Beans gerables 
par le conteneur leger. 

Nous detaillons dans les sections qui suivent la facon dont les differentes notions introdui- 
tes par la POA sont utilisables avec Spring AOP. 

Definition d'un aspect 

Comme explique precedemment, en POA, la notion d' aspect est 1' equivalent de celle 
d'objet en POO. Nous allons voir comment cette notion est implementee par Spring AOP. 

Pour designer la notion d' aspect, Spring AOP emploie le terme advisor, en reference a la 
notion d' advice (que nous avons francise en greffon, plus parlant pour le lecteur). Spring 
AOP propose plusieurs types d'advisors, dont 1' implementation de base est Def aul tPoi nt- 
cutAdvisor, que nous avons eu l'occasion d'utiliser dans notre exemple introductif. 
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Cette implementation de base fixe le principe fondamental de 1' advisor, qui consiste a 
associer une coupe et un greffon. Les types derivant cette implementation sont des clas- 
ses permettant de parameter directement la coupe plutot que de la specifier sous forme 
de Bean specifique, comme nous l'avons fait dans l'exemple introductif. Deux types 
d' advisor directement prets a l'emploi sont proposes par le framework. 

Les aspects de type NameMatchMethodPointcutAdvisor 

NameMatchMethodPointcutAdvisor est un advisor specialise, qui evite de devoir definir une 
coupe fondee sur les noms de methodes sous forme de Bean dedie, comme nous l'avons 
fait dans notre exemple. 

Nous pouvons done supprimer la definition du Bean observerPointcut en remplacant 
1' advisor actuel par le suivant : 

<bean id=" observer Advisor" cl a ss=" org. springf ramework.aop. support. 
NameMatchMethodPointcutAdvisor"> 

<property name="advi ce" ref="observerAdvice"/> 

<property name="mappedNames" 

val ue="getTodo,saveTodo, removeTodo"/> 

</bean> 

Les aspects de type RegexpMethodPointcutAdvisor 

RegexpMethodPointcutAdvisor permet d'utiliser des expressions regulieres pour definir les 
noms des methodes a intercepter. II est done beaucoup plus puissant que l'advisor prece- 
dent, pour lequel la liste complete des methodes doit etre fournie, ce qui peut devenir 
rapidement rebarbatif . 

Cet advisor dispose de deux proprietes, pattern et patterns. La premiere doit etre initiali- 
see quand une seule expression reguliere est necessaire pour specifier la coupe. La 
seconde est un tableau de chaines de caracteres a utiliser lorsque plusieurs expressions 
regulieres sont necessaires. 

En reprenant notre exemple, nous utilisons cet advisor de la maniere suivante : 

<bean id="observerAdvisor" class=" org. springf ramework.aop. support. 
RegexpMethodPoi ntcutAdvi sor" > 

<property name="advi ce" ref="observerAdvice"/> 

<property name="pattern" 
value="*Todo"/> 

</bean> 

Nous devons etre tres prudents en utilisant cet advisor, car nous courons le risque d'inter- 
cepter plus de methodes que necessaire. Typiquement, TodoDAO n'est pas la seule classe 
ayant des methodes sufhxees par Todo. Pour eviter ce type de probleme, il est possible de 
restreindre la portee des advisors en parametrant un proxy specifique (voir la section 
consacree au tissage des aspects). 
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Portee des aspects 

Dans Spring AOP, la portee des aspects est limitee par rapport a des outils de POA 
supportant l'ensemble des concepts de ce nouveau paradigme. Spring AOP se limite a 
intercepter 1' execution de methodes des Beans geres par le conteneur leger. II n'est done 
pas possible d' intercepter une classe de 1' application qui ne serait pas definie sous forme 
de Bean. Cette limitation n'est toutefois guere penalisante, car l'essentiel des developpements 
impliquant des aspects repose sur des coupes de ce type. 

Par defaut, les aspects de Spring AOP sont des singletons, e'est-a-dire qu'ils sont parta- 
ges par l'ensemble des classes et des methodes qu'ils interceptent. II est possible de 
changer ce mode d'instanciation en utilisant la propriete singleton (a ne pas confondre 
avec le parametre singleton du tag bean) des proxy specifiques, que nous abordons plus 
loin. 



Les coupes 

Dans Spring AOP, la notion de coupe est formalisee sous la forme de l'interface Pointcut, 
definie dans le package org.springframework.aop. Cette interface specifie deux methodes, 
getClassFilter et getMethodMatcher, permettant de savoir quelles sont les classes et 
methodes concernees par la coupe. 

Cette interface dispose de plusieurs implementations, utilisables directement pour definir 
les coupes de nos aspects. Les deux principales sont NameMatchPointcut, que nous avons 
utilisee dans notre exemple introductif, et JdkRegexpMethodPointcut, version plus evoluee 
de la precedente. 

Spring AOP offre en outre la possibility de realiser des combinaisons de coupes en 
supportant les operations ensemblistes union et intersection. 

Les coupes de type NameMatchPointcut 

La classe NameMatchPointcut permet de definir des coupes sur des noms de methodes. Elle 
possede deux proprietes, mappedName et mappedNames, dont l'une des deux doit etre initialisee 
par le conteneur leger lors de la declaration de la coupe sous forme de Bean. 

La premiere, de type String, doit etre utilisee lorsqu'il n'y a qu'un seul nom de methode 
a specifier pour la coupe. La seconde, que nous utilisons dans notre exemple introductif, 
doit etre utilisee lorsque plusieurs noms de methodes doivent etre pris en compte. Les 
noms specifies doivent etre des noms exacts. Si aucun filtre de classe n'est specifie, tous 
les Beans concernes par le tissage de 1' aspect sont pris en compte. 

Bien qu'il soit possible de specifier un filtre pour ce type de coupe, il est preferable 
d'utiliser 1' implementation plus puissante proposee par JdkRegexpMethodPointcut, que 
nous detaillons a la section suivante. L' utilisation de NameMatchPointcut doit etre reservee 
aux besoins simples. 
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Les coupes de type JdkRegexpMethodPointcut 

La classe JdkRegexpMethodPointcut permet de specifier les methodes a intercepter sous 
forme d'expression reguliere. Cette specification porte sur le nom pleinement qualifie de 
la methode, c'est-a-dire en mentionnant le package et la classe auxquels elle appartient. 
Nous pouvons done effectuer un filtrage sur ces deux criteres. 

Les expressions regulieres peuvent utiliser le symbole * pour remplacer zero ou plusieurs 
caracteres. Ainsi, nous pouvons specifier 1' expression reguliere suivante pour notre 
exemple : 

tudu.domain.dao. TodoDAO.* 

Pour avoir une expression reguliere plus concise, nous pouvons aussi ecrire : 

| .*TodoDA0.* 

Bien entendu, cette expression reguliere intercepte toutes les methodes de toutes les clas- 
ses ou interfaces suffixees par TodoDAO. Le choix entre classe et interface depend du mode 
de tissage choisi. Par defaut, Spring ne prend en compte que les interfaces, mais il est 
possible de ne prendre en compte que les classes, comme nous le verrons a la section 
consacree au tissage. 

Cette classe dispose de deux proprietes, pattern et patterns. La premiere, de type String, 
doit etre utilisee lorsque la coupe est exprimable sous la forme d'une expression reguliere 
unique. La seconde, qui est un tableau de Stri ng, doit etre utilisee lorsque la coupe neces- 
site plusieurs expressions regulieres dont 1' union produit le resultat attendu. 

Dans notre exemple introductif, nous pouvons remplacer l'utilisation de NameMatchPoint- 
cut par cette classe, afin d' avoir une definition de coupe plus generique : 

<bean id="observerPointcut" 
cl ass="org.springf ramework. sop. support. OdkRegexpMethodPointcut"> 

<property name="pattern" val ue="tudu.domain.dao. TodoDAO. *"/> 

</bean> 

Notons que cette classe impose l'utilisation de J2SE en version 1.4 au minimum. Si nous 
utilisons une version anterieure, nous devons remplacer cette classe par la classe 
Perl 5RegexpMethodPoi ntcut, qui offre le meme service sans dependre de la version de Java 
utilisee. 

Combinaison de coupes 

Spring AOP offre la possibilite d' utiliser les operateurs ensemblistes union et intersection 
avec les coupes afin de specifier des coupes composites. L'operateur union etant le plus 
utilise, il beneficie d'une classe implementant l'interface Poi ntcut, facilement utilisable 
sous forme de Bean. 
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La classe UnionPointcut permet de faire l'union de deux coupes specifiers par ailleurs sous 
forme de Beans. Notons que cette classe ne supporte que 1' injection par constructeur. 
Son constructeur prend en parametres les deux coupes a unir. 

En reprenant notre exemple, nous pouvons definir deux coupes dont l'union produit la 
coupe utile pour notre aspect : 

<bean id="observerPointcutl" 

cl ass= "org. springf ramework. aop. support. NameMatchMethodPointcut"> 
<property name="mappedName" 
val ue="getTodo "/> 

</bean> 

<bean id="observerPointcut2" 
cl ass=" org. springf ramework. aop. support. NameMatchMethodPointcut"> 
<property name="mappedNames" 

val ue="saveTodo , removeTodo"/> 

</bean> 

<bean id="observerPointcut" 

cl ass="org. springf ramework. aop. support. Uni on Pointcut"> 

<constructor-arg ref="observerPointcutl"/> 

<constructor-arg ref="observerPointcut2"/> 
</bean> 

Pour beneficier de l'operateur intersection, il est necessaire d'utiliser la classe Composa- 
blePointcut, qui propose les deux operateurs ensemblistes. Malheureusement, cette 
classe n'est pas instanciable directement par le conteneur leger. II est done necessaire de 
creer une fabrique specifique pour ce faire. L' utilisation de l'operateur etant marginale 
pour la definition de coupes, nous ne l'abordons pas dans cet ouvrage. 



Les greffons 

Les greffons sont specifies sous forme de Beans. Avec Spring AOP, ces Beans doivent 
implementer des interfaces specifiques. Afin de permettre aux greffons de realiser des 
traitements en fonction de leur contexte d' execution, ces interfaces leur permettent 
d'acceder a des informations detaillees sur les methodes interceptees. 

Spring AOP supporte nativement quatre types de greffons. Chacun d'eux est formalise 
par une interface specifique. Cette interface specifie une methode devant declencher le 
traitement du greffon. Cette methode contient plusieurs parametres, fournissant des 
informations sur 1' interception. 

Les greffons de type around 

Les greffons de type around, appeles aussi intercepteurs, doivent implementer l'interface 
Met hod Interceptor du package org. aopalliance. intercept. Elle fait partie de l'API generique 
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definie par l'AOP Alliance, dont l'objectif est d' assurer l'interoperabilite des outils de 
POA. Cette interface specifie la methode invoke, dont la signature est la suivante : 

public Object invoke(MethodInvocation invocation) throws Throwable 

Le parametre invocation permet d'acceder aux informations concernant la methode inter- 
cepted (nom, classe d'appartenance, arguments, etc.)- Ce parametre dispose d'une 
methode proceed, a appeler pour declencher l'execution de la methode interceptee. 

Nous pouvons reecrire le greffon de notre exemple introductif en utilisant cette inter- 
face : 

(...) 

import org.aopal 1 iance. intercept. Method Interceptor: 
import org.aopal 1 iance. intercept. Method Invocation; 

public class ObserverAdvi ce implements Methodlnterceptor { 
(...) 

public Object invoke(MethodInvocation invocation) 

throws Throwable { 
Object ret = invocation. proceedO; 
event.fi reEventt ) ; 
return ret; 

} 

} 

Les greffons de type before 

Les greffons de type before doivent implementer l'interface MethodBeforeAdvice du 
package org.springframework.aop. Cette interface specifie la methode before, dont la signa- 
ture est la suivante : 

public void before(Method method, Object[] args, Object target) 
throws Throwable 

Le parametre method permet d'acceder aux informations concernant la methode intercep- 
tee. Les arguments de la methode sont contenus dans le parametre args. Le parametre 
target contient la reference a l'objet possedant la methode interceptee. 

Nous pouvons reecrire le greffon de notre exemple introductif en utilisant cette inter- 
face : 

(...) 

i mport j a va . 1 ang . ref 1 ect . Method ; 

import org.springframework.aop. MethodBeforeAdvice; 

public class ObserverAdvice implements MethodBeforeAdvice { 
(...) 
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public void beforeCMethod method, Object[] args. Object target) 

throws Throwable { 

event.fi reEvent( ) ; 

} 

} 

En utilisant ce type de greffon, la generation s'effectue avant l'execution de la methode 
interceptee, et non plus apres, comme dans l'exemple introductif. 

Les greffons de type after returning 

Les greffons de type after returning doivent implementer l'interface AfterReturning- 
Advice du package org.springframework.aop. Cette interface specifie la methode after- 
Returning, dont la signature est la suivante : 

public void afterReturningtObject returnVal ue. Method method, 

Object[] args, Object target) throws Throwable 

Le parametre returnVal ue donne acces a la valeur de retour qui a ete renvoyee par la 
methode interceptee. Les autres parametres ont la meme signification que ceux des greffons 
de type before. 

C'est ce type de greffon que nous utilisons dans notre exemple introductif. 
Les greffons de type after throwing 

Les greffons de type after throwing doivent implementer l'interface ThrowsAdvice du 
package org.springframework.aop. Contrairement aux interfaces precedentes, celle-ci ne 
specifie pas de methode. Spring AOP utilise ici la reflexivite pour detecter une methode 
sous la forme suivante : 

public void afterThrowing(Method method, Object[] args. 

Object target, Throwable exception) 

L' utilisation de la reflexivite permet de remplacer le type du dernier parametre exception 
par n'importe quelle classe ou interface derivant de Throwable. II s'agit generalement du 
type de l'exception generee par les methodes interceptees contenues dans exception. 

L implementation suivante de notre greffon declenche l'evenement uniquement si une 
des methodes de TodoDAO genere une exception : 

(...) 

import java.lang. reflect. Method; 

import org.springframework.aop. ThrowsAdvice; 

public ObserverAdvice implements ThrowsAdvice { 

(...) 

public void afterThrowing(Method method, Object[] args. 
Object target, Throwable e) { 

event.fi reEvent( ) ; 

} 

} 
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Utilisation de Spring AOP avec AspectJ 

Depuis la version 2.0 de Spring, le support de la POA par le framework progresse de 
maniere significative grace au support natif d'une partie des fonctionnalites d'AspectJ. 

II s'agit essentiellement du support du langage de specification de coupe propre a 
AspectJ, ainsi que des annotations Java 5, qui permettent de definir un aspect a partir 
d'une simple classe Java. 

Fondamentalement, les capacites du framework sont les memes. Les progres se situent 
dans le moindre effort de programmation necessaire et dans une plus grande indepen- 
dance du code des aspects vis-a-vis de Spring AOP, puisqu'il n'y a plus d' interfaces du 
framework a implemented 

Definition d'un aspect 

Le support d'AspectJ permet de definir un aspect selon deux formats. Le premier est 
fonde sur XML, et le second sur les annotations Java 5. Les sections suivantes detaillent 
ces deux formats. 

Le format XML 

Comme indique dans l'exemple introductif, la definition d'un aspect sous forme XML 
s'effectue via le tag aop : aspect. La notion d'aspect est associee a un Bean devant contenir 
1' ensemble des greffons utilises par 1' aspect via le parametre ref du tag. Chaque greffon 
est materialise sous la forme d'une methode. 

La definition de la coupe s'effectue directement dans le fichier de configuration, sans 
necessiter la creation d'un Bean specifique. La definition de la coupe s'effectue via une 
expression reguliere specifique d'AspectJ, que nous decrivons a la section dediee aux 
coupes. 

Dans notre exemple introductif, la coupe est definie separement de 1' association avec le 
greffon effectuee par le tag aop: advice. Elle est alors referencee par le parametre point- 
cut-ref. Lavantage de cette solution est que cette forme permet de reutiliser cette coupe 
avec un autre greffon. 

Si cela n'est pas necessaire, il est possible de definir la coupe directement dans le tag, 
avec le parametre pointcut : 

<aop:config> 

<aop:aspect id="observerAspect" ref="observerAdvice"> 
<aop:advice 

kind=" after Returning" method^" greffon" 
pointcut="execution(* tudu.domain.dao.TodoDAO.*( ..))"/> 

</aop:aspect> 
</aop:config> 
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Utilisation des annotations Java 5 

Les annotations Java 5 permettent de definir un aspect directement a partir du Bean 
contenant les greffons. 

Ainsi, nous pouvons creer la classe ObserverAspect, qui implemente notre aspect en 
copiant la classe ObserverAdvi ce et en lui ajoutant les annotations et le code en gras : 

package tudu. aspects. observer. a spectj ; 

import org . aspect j . 1 ang . annotati on .After Returni ng ; 
import org. aspect j .1 ang. annotati on. Aspect; 

import tudu. service. events. Event; 

@Aspect 

public class ObserverAspect { 
private Event event; 

public Event getEventO { 
return event; 

} 

public void setEvent(Event event) { 
this. event = event; 

} 

@AfterReturning("execution(* tudu.domain.dao.TodoDAO.*( ..))") 

public void greffonO { 
event.fi reEvent( ) ; 

} 

} 

Le marquage de la classe comme etant un aspect est assure par l'annotation ©Aspect. La 
definition du greffon et de son type ainsi que de la coupe associee est effectuee par 
l'annotation @Af terReturni ng. II existe une annotation par type de greffon, comme nous le 
verrons a la section dediee a ces derniers. 

Meme si les annotations prennent en charge 1' ensemble de la definition de 1' aspect, il 
reste necessaire d'avertir le conteneur leger de la presence d' aspects definis de la sorte. 

II faut utiliser le tag aop:aspectj-autoproxy pour les tisser et declarer les aspects sous 
forme de Bean : 

<aop: aspect j-autoproxy/> 



<bean id="observerAspect" 

cl ass= "tudu. aspects .observer. aspect j . ObserverAspect "> 
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<property name="event"> 

<bean class="tudu. service. events. impl .Eventlmpl "> 
<property name="l isteners"> 
<set> 

<bean class="tudu. aspects. observer. DummyObserver'7> 
</set> 
</property> 
</bean> 
</property> 
</bean> 



Portee des aspects 

Les aspects definis avec le support d' AspectJ sont des singletons par defaut. II est possi- 
ble de controler leur instanciation s'ils sont definis en utilisant les annotations. Seuls les 
Beans geres par le conteneur leger peuvent etre tisses avec les aspects. 

L' annotation ©Aspect accepte les parametres perthis et pertarget a cette fin. Leur utilisa- 
tion assez complexe depassant le perimetre de notre introduction a la POA, nous ne 
l'abordons pas dans le cadre de cet ouvrage. 



Les coupes 

La specification des coupes en utilisant le support d' AspectJ ne necessite pas 1' instanciation 
de Beans specifiques, contrairement a l'approche precedente. 

Les coupes sont specifiers sous forme d'expressions regulieres selon un format propre a 
AspectJ. 

Le support d' AspectJ propose par Spring AOP ne comprend qu'un seul type de point de 
jonction, execution, qui intercepte les executions de methodes. A ce point de jonction est 
associee une expression reguliere specifiant les methodes a intercepter. 

AspectJ fournit un mecanisme permettant, a l'aide de symboles specifiques, de creer des 
expressions englobant plusieurs methodes. Ces symboles sont appeles des wildcards. Le 
mecanisme de wildcard fournit une syntaxe riche, permettant de decrire de nombreuses 
coupes. En contrepartie, cette richesse peut conduire a des expressions de coupe complexes 
et subtiles. Nous decrivons ici les usages les plus courants de ces wildcards. 

Noms de methodes et de classes 

Le symbole * peut etre utilise pour remplacer des noms de methodes ou de classes. Nous 
verrons qu'il peut l'etre egalement pour des signatures de methodes et des noms de 
packages. 

En ce qui concerne les methodes, le symbole * designe tout ou partie des methodes d'une 
classe ou d'une interface. 
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L' expression suivante designe l'execution de toutes les methodes publiques de l'interface 
TodoDAO prenant en parametre une chaine de caracteres et retoumant void : 

execution (public void tudu. domain, dao. TodoDAO. MString)) 

Le symbole * peut etre combine avec des caracteres afin de designer, par exemple, toutes les 
methodes qui contiennent la sous-chaine Todo dans leur nom. Dans ce cas, l'expression 
s'ecrit *Todo*. 

Le symbole * peut aussi etre utilise pour les noms de classes ou d'interfaces. L'expres- 
sion suivante designe l'execution de toutes les methodes publiques de toutes les classes 
ou interfaces du package tudu. domain. dao, qui prennent en parametre une String et qui 
retournent void : 

j execution(public void tudu. domain. dao. *.*(String)) 

Signatures de methodes 

Au-dela des noms, les parametres, types de retour et attributs de visibilite (public, 
protected, private) jouent un role dans 1'identification des methodes. AspectJ offre la 
possibility de les inclure dans les expressions de coupes. 

Les parametres de methodes peuvent etre omis grace au symbole ... L'expression 
suivante designe l'execution de toutes les methodes publiques retournant void de l'inter- 
face TodoDAO, quel que soit le profil de leurs parametres : 

execution(public void tudu. domain .dao. TodoDAO. *(..) ) 

Le type de retour et la visibilite d'une methode peuvent quant a eux etre omis a l'aide du 
symbole *. 

L'expression suivante designe l'execution de toutes les methodes de l'interface TodoDAO, 
quels que soient leurs parametres, type de retour et visibilite : 

executions * tudu. domain .dao. TodoDAO. *(..) ) 

De facon complementaire, le symbole * pour remplacer l'attribut de visibilite peut etre 
omis, sans que cela change la portee de la coupe. 

L'expression suivante est identique a la precedente : 

execution(* tudu. domain. dao. TodoDAO. *( . . ) ) 

Noms de packages 

Les noms de packages peuvent etre remplaces par le symbole . . . 

Par exemple, l'expression suivante designe l'execution de toutes les methodes de toutes 
les classes TodoDAO dans n'importe quel package de la hierarchie tudu, quel que soit le 
niveau de sous-package de cette hierarchie : 

executions tudu. .TodoDAO. *(..) ) 
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Combinaisons de coupes 

II est possible avec AspectJ de specifier des coupes composites en utilisant les operateurs 
and (intersection), or (union) et not (exclusion). 

Nous pouvons ainsi definir une coupe sur toutes les methodes de l'interface TodoDAO, sauf 
la methode getTodo : 

executions tudu. domain .dao. TodoDAO. *(..) ) and 

not executiont* tudu. domain .dao. TodoDAO. getTodot ..) ) 

Les greffons 

Avec le support d' AspectJ, les greffons sont simples a definir, car ils ne supposent pas 
1' implementation d'interfaces specifiques. Cette definition peut s'effectuer de deux 
manieres : en utilisant le fichier de configuration XML du conteneur leger ou en utilisant 
les annotations. 

Rappelons que, pour utiliser les annotations, il est necessaire de disposer d'une JVM 
version 5 au minimum. A l'instar des interfaces de Spring AOP, les greffons AspectJ ont 
la capacite d'acceder a des informations sur la methode interceptee selon deux methodes, 
que nous abordons dans cette section. 

Lorsque le fichier de configuration est utilise pour creer les aspects de 1' application, la 
definition du type des greffons s'effectue via le parametre kind du tag aop: advice. Ce 
parametre peut prendre cinq valeurs differentes, correspondant aux differents types de 
greffons : before, after, around, afterReturning et afterThrowing. Pour tous ces types sauf 
around, il suffit de changer ce parametre sans autre modification. 

Pour le type around, il est necessaire de modifier la signature du greffon arm qu'il recoive 
en parametre un objet de type ProceedingJoinPoint, qui donne acces a la methode proceed. 
Par ailleurs, le greffon doit pouvoir transmettre les exceptions et les valeurs de retour 
susceptibles d'etre generees par proceed. 

Si nous transformons le greffon de notre exemple d' introduction en type around, nous 
obtenons le resultat suivant : 

(...) 

import org. aspect j .1 ang. ProceedingJoinPoint: 

(...) 

public Object greffon(ProceedingJoinPoint thisJoinPoint) 

throws Throwable { 
Object ret = thisJoinPoint. proceed( ) ; 

event.fi reEventt ) ; 
return ret; 

} 

Lorsque la definition des aspects s'effectue par annotation, nous disposons d'une annotation 
par type de greffon. 
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En plus de ©AfterReturning, que nous avons deja rencontre, nous disposons de ©Before, 
©After, ©Around et ©AfterThrowing, qui fonctionnent tous selon le meme principe. 

A l'instar de la configuration XML, les greffons de type around doivent etre modifies pour 
prendre en parametre l'objet donnant acces a la methode proceed : 

(...) 

import org. aspect j .lang.ProceedingJoinPoint; 
(...) 

@Around("execution(* tudu.domain.dao.TodoDAO.*( ..))") 

public Object greffon(ProceedingJoinPoint thisJoinPoint) 

throws Throwable { 
Object ret = thi sJoinPoint .proceed( ) ; 
event.fi reEvent( ) ; 
return ret; 

} 

Notons que le support d'AspectJ propose le type after, non specifie sous forme d'inter- 
face par Spring AOP. Ce type est l'equivalent de afterReturning et de afterThrowing 
reunis. II est appele quel que soit le resultat de 1' execution de la methode interceptee 
(valeur de retour ou exception). 

Introspection et typage des coupes 

Les greffons d'AspectJ ont la possibility d'acceder aux informations concernant la 
methode interceptee. Cet acces peut se faire de deux manieres : en utilisant un objet de 
type JoinPoint (dont le type ProceedingJoinPoint utilise par les greffons de type around 
derive), permettant 1' introspection de la methode interceptee, ou en typant les coupes. 

Pour pouvoir realiser une introspection de la methode interceptee, il est necessaire de 
specifier comme premier parametre (obligatoire) un argument de type JointPoint (ou 
derive). Cette modification est valable en configuration XML et avec les annotations. 

Si nous desirons introspecter la methode interceptee par notre exemple d'observateur, 
nous pouvons modifier notre greffon de la maniere suivante : 

(...) 

import org. aspect j . 1 ang. JoinPoint; 

(...) 

public void greffon(JoinPoint thisJoinPoint) { 
System. out. printlnC'Appel de la methode : " 
+thisJoinPoint.getSignature( ) .getName( )) ; 

event.fi reEvent( ) ; 

} 

La methode getSignature de la classe JoinPoint permet d'avoir des informations sur la 
signature de la methode (nom, portee, etc.) sous la forme d'un objet de type 
org. aspect j.lang. Signature. Dans notre exemple, nous utilisons la methode getName pour 
obtenir le nom de la methode. 
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La classe JoinPoint possede d'autres methodes, souvent utiles pour les greffons : 

• getThis : renvoie la reference vers le proxy utilise pour 1' interception (voir la section 
consacree au tissage). 

• getTarget : renvoie la reference vers l'objet auquel appartient la methode interceptee. 

• getArgs : renvoie la liste des arguments passes en parametres a la methode interceptee 
sous forme d'un tableau d'objets. 

Typage de la coupe 

La recuperation des informations sur la methode interceptee peut s'effectuer de maniere 
fortement typee (contrairement a 1' introspection, que nous venons de voir). Pour cela, 
nous pouvons associer ces informations a des parametres formels du greffon. 

Ainsi, les resultats de getThis, getTarget et getArgs peuvent etre directement accessibles 
depuis des parametres du greffon. Pour la derniere methode, il est possible de specifier 
une liste fixe et typee d' arguments, evitant ainsi d'utiliser la reflexivite dans le code du 
greffon. 

Les greffons de types afterReturning et afterThrowing peuvent avoir acces respectivement 
a la valeur de retour ou a 1' exception renvoyee par la methode interceptee. 

this et target 

La specification des parametres this et target s'effectue a deux niveaux : dans la coupe, 
en complement de l'expression reguliere associee au point de jonction execution, et au 
niveau du greffon, sous la forme d'un parametre. 

Si nous voulons recuperer dans le greffon de notre exemple une reference a l'objet dont 
la methode a ete interceptee, nous devons modifier notre coupe de la maniere suivante : 

executions tudu. domain. dao. TodoDAO. *(.. )) and target(todoDAO) 

Le nom todoDAO donne ici doit correspondre au nom du parametre correspondant dans le 
greffon. 

Notre greffon peut s'ecrire maintenant de la maniere suivante : 
(...) 

import tudu. domain. dao. TodoDAO; 
(...) 

public void greffon(TodoDAO todoDAO) { 
(...) 

event.fi reEventt ) ; 

} 

L'utilisation de thi s est identique a celle de target. Le type de parametre doit etre Object, 
car il s'agit d'une reference a un proxy dynamique dont la classe ne peut etre connue a 
l'avance. 
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args 

Comme avec this et target, les arguments a recuperer doivent etre specifies dans la 
coupe a l'aide du parametre args et au niveau des arguments du greffon. 

Si nous voulons recuperer l'identifiant du todo (qui est une chaine de caracteres), nous 
devons specifier la coupe de la maniere suivante : 

execution(* tudu. domain. dao. TodoDAO. *(..) ) and args(id) 

Notre greffon peut s'ecrire maintenant de la maniere suivante : 

(...) 

public void greffontString id) { 
(...) 

event.fi reEvent( ) ; 

} 

Le fait de specifier de maniere formelle les arguments recuperes par le greffon exclut 
d' office les methodes dont les arguments ne correspondent pas a ceux attendus. Ainsi, la 
methode saveTodo precedemment interceptee ne Test plus avec la nouvelle coupe, car son 
unique argument est de type Todo et non String. 

II est possible de specifier une liste d'arguments dans le parametre args en les sepa- 
rant par des virgules. Les symboles * et . . sont autorises pour specifier des argu- 
ments dont le type est indefini et qui ne doivent pas etre associes avec les arguments 
du greffon. 



returning 

Les greffons de type afterReturning doivent pouvoir acceder a la valeur de retour de la 
methode interceptee. Pour ce faire, il est possible de declarer un argument du greffon 
comme etant destine a recevoir cette information. 

Pour la configuration XML, il faut utiliser le parametre returning dans le tag aop: advice 
en lui fournissant le nom de l'argument du greffon : 

<aop:advice 

kind=" after Returning" 
method="greffon" 
pointcut-ref=" coupe" 
returning="returnValue" 

/> 

Pour les annotations, il faut utiliser le parametre returning de ©AfterReturning : 

@AfterReturning( 

pointcut="execution(* tudu. domain. dao. TodoDAO. *( . . ) ) " 
,returning="returnValue") 
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Dans les deux cas, le greffon devient le suivant : 
(...) 

import tudu. domain. model .Todo; 
(...) 

public void greffon (Todo returnValue) { 
(...) 

event.fi reEventt ) ; 

} 

Avec cette nouvelle coupe, seule la methode getTodo de TodoDAO est interceptee puisque 
les autres ne renvoient pas de valeur. 



Les greffons de type afterThrowing doivent pouvoir acceder a l'exception generee par la 
methode interceptee. La encore, il est possible pour ce faire de declarer un argument du 
greffon comme etant destine a recevoir cette information. 

Pour la configuration XML, il faut utiliser le parametre throwi ng dans le tag aop : advi ce en 
lui fournissant le nom de 1' argument du greffon : 

<aop: advice 

kind=" after Returning" 
method="greffon" 
pointcut-ref=" coupe" 
throwi ng="excepti on" 



Pour les annotations, il faut utiliser le parametre returning de ©AfterReturning : 

©AfterThrowing ( 

pointcut="execution(* tudu. domai n .dao. TodoDAO. *( . . ) )" 
,throwing="exception") 

Dans les deux cas, le greffon devient le suivant : 

(...) 

import tudu. domain. model .Todo; 
(...) 

public void greffon(Throwable exception) { 



L'exception en parametre d'un greffon de type afterThrowing peut etre d'un type derivant 
de Throwable. Nous utilisons ici Throwable, car nous ne pouvons prejuger des exceptions 
generees par la methode interceptee (elle ne specifie pas d'exception via la clause throws, 
par exemple). 




throwing 



/> 



(...) 

event.fi reEventt ) ; 
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Le mecanisme d'introduction 

Spring AOP dispose d'un mecanisme d'introduction utilisant un type de greffon (Del ega- 
tinglntroductionlnterceptor) et un type d'advisor (DefaultlntroductionAdvisor) specifi- 
ques. Avec le support d'AspectJ apporte par la version 2.0 de Spring, nous avons la possi- 
bility de nous reposer sur cette technologie pour realiser des introductions. La solution 
d'AspectJ etant plus elegante que la solution native de Spring AOP, nous ne presentons 
ici que la premiere. 

Le mecanisme d'introduction d'AspectJ est uniquement utilisable sous forme d' annota- 
tions a l'heure oil nous ecrivons ces lignes. II repose sur l'annotation @Decl areParents, qui 
prend deux parametres : value, qui designe la classe cible a etendre, et defaultlmpl, qui 
specifie la classe fournissant 1' implementation de 1' introduction. Cette classe doit bien 
entendu implementer l'interface qui est introduite dans la classe cible. La specification de 
cette interface est fournie par l'attribut statique auquel s'applique l'annotation @Decl are- 
Parents. 

Si nous desirons etendre les fonctionnalites de la classe TodoListDAOHibernate du package 
tudu. domain. dao.hibernate3 afin qu'elle implemente l'interface java.util .Observer, nous 
pouvons specifier 1' aspect suivant : 

package tudu. aspects. observer. a spectj ; 

import java.util .Observer; 

import org. aspect j . lang. annotation. Aspect; 

import org. aspect j.lang.annotati on. Decl areParents; 

import tudu. aspects. observer. DummyObserver; 

©Aspect 

public class Observerlntroduction { 

@Decl areParents( 

val ue="tudu.domain.dao. hi bernate3. TodoListDAOHibernate" 
.defaultlmpl =DummyObserver.cl ass) 
public static Observer mixin; 

) 

Nous specifions comme implementation de 1' introduction la classe DummyObserver de 
notre exemple introductif, qui implemente l'interface java.util. Observer. 

Pour que l'introduction soit effective, il est necessaire de declarer Observerlntroduction 
sous forme de Bean et d'utiliser le tag aop: aspect j-autoproxy pour que le tissage s'effec- 
tue : 

<aop: aspect j-autoproxy/> 



<bean id="observer Introduction" 

class="tudu. aspects. observer. aspect j . Observer Introduction"/> 
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Nous pouvons maintenant modifier le greffon observerAdvice afin qu'il utilise le Bean todo- 
ListDAO comme observateur, puisque celui-ci implemente l'interface java.util .Observer 
grace a 1' introduction : 

<bean id= "observerAdvice" class="tudu. aspects. observer. aspect j .ObserverAdvi ce"> 
<property name="event"> 

<bean cl ass="tudu.servi ce. events .impl . Event Imp! "> 
<property name="l isteners"> 
<set> 

<ref bean="todoListDAO"/> 

</set> 
</property> 
</bean> 
</property> 
</bean> 

<aop:config> 

<aop:aspect id="observerAspect" ref="observerAdvice"> 
<aop:advice 

kind=" after Returning" method=" greffon" 
pointcut="execution(* tudu.domain.dao.TodoDAO.*( . . ) ) " 

/> 

</aop:aspect> 
</aop:config> 

Si nous executons 1' application Web avec ces modifications, nous constatons que le Bean 
todoLi stDAO se comporte effectivement en observateur en lieu et place du Bean interne de 
type DummyObserver. 



Le tissage des aspects 

Le tissage des aspects avec Spring AOP et son support d'AspectJ s'effectue grace a la 
creation dynamique de proxy pour les Beans dont les methodes doivent etre interceptees. 
Les utilisateurs de ces methodes obtiennent ainsi une reference a ces proxy (dont les 
methodes reproduisent rigoureusement celles des Beans qu'ils encapsulent), et non une 
reference directe aux Beans tisses. 

La generation de ces proxy est controlee au niveau du fichier de configuration du conte- 
neur leger. Cette generation peut etre automatique pour les besoins courants ou specifique 
pour les besoins plus complexes. 

Avec AspectJ, le tissage est uniquement automatique. Le seul controle dont dispose le 
developpeur est de tisser ou non les aspects a base d' annotations via le tag aop : aspect j- 
autoproxy. 

Les proxy automatiques 

Dans notre exemple introductif, nous avons utilise le mecanisme de proxy automatique 
afin de simplifier notre configuration. Spring AOP propose des modes de tissage automa- 
tique materialises par des Beans specifiques a instancier. 
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Le mode le plus simple est celui utilise dans notre exemple. II utilise la classe DefaultAd- 
visorAutoProxyCreator, qui doit etre instanciee sous forme de Bean dans le conteneur 
leger : 

<bean class=" 

org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/> 

Ce mode se fonde sur les coupes gerees par 1' ensemble des advisors de 1' application pour 
identifier les proxy a generer automatiquement. Dans notre exemple, les Beans ayant une 
ou plusieurs methodes specifiees dans la coupe observerPointcut sont automatiquement 
encapsules dans un proxy. 

Le second mode permet de specifier la liste des Beans a encapsuler dans des proxy. Ce 
mode utilise la classe BeanNameAutoProxyCreator, qui doit etre instanciee sous forme de 
Bean dans le conteneur leger : 

<bean cl ass= "org. springframework.aop.f ramework.autoproxy . BeanNameAutoProxyCreator" > 

<property name="beanNames" val ue="todoDA0"/> 
<property name=" interceptor Names "> 
<list> 

<val ue>observerAdvi sor</val ue> 
</list> 
</property> 
</bean> 

Ce tisseur prend en parametre la liste des Beans a tisser sous forme d'un tableau de chai- 
nes de caracteres via la propriete beanNames (l'utilisation du symbole * est autorisee) et la 
liste des advisors a y appliquer via la propriete interceptorNames. Cette propriete accepte 
egalement les greffons dans sa liste. Dans ce cas, les greffons interceptent l'ensemble des 
methodes des Beans concernes par le tissage. 

Dans notre exemple, comme nous interceptons l'ensemble des methodes du Bean todo- 
DAO, nous pouvons utiliser directement le greffon observerAdvice, sans passer par l'advi- 
sor : 

<bean cl as s= "org. springframework.aop.f ramework.autoproxy . BeanNameAutoProxyCreator" > 

<property name="beanNames" val ue="todoDA0"/> 
<property name=" interceptor Names "> 
<list> 

<val ue>observerAdvice</val ue> 

</list> 
</property> 
</bean> 

Les proxy specif iques 

Les proxy specifiques offrent un controle plus etroit sur leur mode de fonctionnement. lis 
permettent de definir s'il faut creer un proxy par rapport a l'interface du Bean ou par 
rapport a sa classe, ainsi que le mode d'instanciation de l'aspect (singleton ou par instance 
de Bean). 
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Les proxy specifiques sont definis sous forme de Beans avec la classe ProxyFactoryBean, 
qui, comme son nom l'indique, est une fabrique de proxy. Ce sont ces Beans qu'il faut 
utiliser en lieu et place des Beans qu'ils encapsulent. Nous perdons ainsi la transparence 
des proxy automatiques du point de vue de la configuration. 

Si nous reprenons notre exemple introductif, la premiere etape consiste a renommer le 
Bean todoDAO en todoDAOTarget (convention de nommage pour designer les Beans devant 
etre tisses specifiquement). Ensuite, nous definissons un nouveau Bean todoDAO de la 
classe ProxyFactoryBean : 

<bean id=" todoDAO" class="org.springframework.aop. framework. Proxy FactoryBean"> 

<property name="target" ref="todoDAOTarget"/> 
<property name=" interceptor Names "> 
<list> 

<val ue>observerAdvisor</val ue> 
</list> 
</property> 
</bean> 

La propriete target specifie le Bean devant etre encapsule dans le proxy (ici, todoDAOTar- 
get). La propriete interceptorNames specifie la liste des advisors ou des greffons a tisser. 

ProxyFactoryBean propose trois proprietes optionnelles : 

• proxylnterfaces : tableau de chaines de caracteres specifiant la liste des interfaces du 
Bean a tisser. Lorsque cette propriete n'est pas specifiee, la detection s'effectue auto- 
matiquement. 

• singleton : booleen specifiant le mode d'instanciation de l'aspect. S'il vaut false, 
1' aspect est instancie pour chaque instance du Bean tisse. Par defaut, cette propriete 
vaut true. 

• proxyTargetClass : booleen specifiant si le proxy doit etre genere sur la classe au lieu 
des interfaces qu'elle implemente. Par defaut, cette propriete vaut f al se. 



Modifications de cibles 

Comme indique a la section precedente consacree au tissage, un proxy encapsule un 
Bean afin d'intercepter les appels a ses methodes. Spring AOP propose un niveau d'indi- 
rection supplementaire grace a la notion de source de cible, modelisee par l'interface 
TargetSource du package org.springframework.aop. 

Cette notion est proche de celle de fabrique de Bean specifique. L'idee est que l'entite de 
resolution de la cible fournit au proxy la reference au Bean. Elle est done en mesure 
de controler cette derniere. Cette capacite permet de remplacer des Beans a chaud ou de 
gerer des pools d'instances de Beans. 

La fabrique ProxyFactoryBean utilise une implementation par defaut, qui renvoie la refe- 
rence du Bean specifiee par sa propriete target. II est possible d'utiliser une des deux 
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implementations que nous allons voir grace a sa propriete targetSource. L' utilisation des 
sources de cibles est compatible avec le tissage d' aspect au sein de la fabrique. 

Remplacement a chaud des cibles 

Le remplacement a chaud des cibles permet de changer d' instance pour un Bean pendant 
l'execution de l'application. Ce remplacement a chaud est assure par la classe HotSwappabl e- 
TargetSource du package org. springf ramework.aop. target. 

Pour beneficier de cette fonctionnalite pour le Bean todoDAO, il sufht de le renommer en 
todoDAOTarget et d'instancier l'entite de resolution de la cible ainsi que la fabrique Proxy- 
FactoryBean de la maniere suivante : 

<bean id=" swapper" cl as s= "org. springf ramework.aop. target. HotSwappabl eTargetSource"> 

<constructor-arg ref="todoDAOTarget"/> 
</bean> 

<bean id=" todoDAO" cl as s=" org. springf ramework.aop. framework. Proxy Factory Bean "> 

<property name="targetSource" ref="swapper"/> 
</bean> 

Le Bean todoDAO peut etre transtype en HotSwappabl eTargetSource. Ce transtypage permet 
d'utiliser la methode swap prenant en unique parametre la nouvelle implementation de 
l'interface TodoDAO a utiliser. 

Pooling des cibles 

Spring AOP permet de creer un pool d'instances d'un Bean, similaire a celui propose par 
les serveurs d' applications avec les EJB Session sans etat. Pour cela, comme pour le 
remplacement a chaud des cibles, il faut utiliser une implementation specifique de 
TargetSource, ici CommonsPool TargetSource, fondee sur la bibliotheque Commons Pool de la 
communaute Apache Jakarta. 

Pour pouvoir beneficier de cette fonctionnalite pour le Bean todoDAO, il suffit de le trans- 
former en prototype (singleton="false"), de le renommer en todoDAOTarget et d'instancier 
l'entite de resolution de la cible ainsi que la fabrique ProxyFactoryBean de la maniere 
suivante : 

<bean id="pool " cl a ss=" org. springf ramework.aop. target. Commons Pool TargetSource" > 

<property name="targetBeanName" val ue="todoDAOTarget"/> 

<property name="maxSize" value="4"/> 
</bean> 

<bean id=" todoDAO" cl a ss=" org. springf ramework.aop. framework. Proxy Factory Bean "> 

<property name="targetSource" ref="pool"/> 
</bean> 

Dans cet exemple, nous creons un pool d'instances du Bean todoDAOTarget ayant au maxi- 
mum quatre instances disponibles. 
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Conclusion 

Nous avons vu dans ce chapitre comment utiliser Spring AOP et son support d'AspectJ 
pour faire de la POA. Nous avons implements a cet effet le design pattern observateur 
afin de demontrer concretement la puissance de ce nouveau paradigme. 

Grace a la richesse de Spring AOP, le developpeur dispose d'une large palette d'outils 
pour definir les aspects qui lui sont necessaires. Cependant, Spring AOP n'offre pas toute 
la richesse fonctionnelle des outils de POA specialises. II ne peut, par exemple, intercepter 
que les executions de methodes des Beans geres par le conteneur leger. 

La couverture fonctionnelle de ce framework reste cependant suffisante pour couvrir la 
plupart des besoins. La gestion des transactions, que nous traitons en detail au chapi- 
tre 12, repose d'ailleurs sur Spring AOP, preuve concrete que ce framework est en mesure 
de supporter des aspects complexes. 

Ce chapitre clot la premiere partie de cet ouvrage, qui a fourni les bases necessaires a 
l'utilisation de Spring. Dans les parties suivantes, nous abordons l'ensemble des fonc- 
tionnalites a valeur ajoutee proposees par ce framework et reposant sur les fondations 
conceptuelles que nous avons introduites. 
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Cette partie se penche sur les principes que Spring met en oeuvre afin de resoudre les 
preoccupations liees aux applications Web. Spring couvre un large spectre de techno- 
logies Web, allant des servlets aux portlets. Le framework s'efforce de garder une 
homogeneite de ses differents supports Web en utilisant des mecanismes similaires. 

Spring n'imposant pas l'utilisation de son framework MVC, nous verrons au chapi- 
tre 6 comment l'utilisation de Spring en conjonction avec Struts, un des frameworks 
MVC les plus utilises actuellement, permet a ce dernier de s'interfacer de maniere 
optimale avec la couche metier des applications Java/J2EE. 

Le chapitre 7 traite de Spring MVC, le framework MVC de Spring. Ce dernier vise a 
fournir un cadre souple et robuste afin d'implementer des applications Web fondees 
sur la technologie servlet tout en tirant parti au maximum des fonctionnalites du conte- 
neur leger de Spring. 

Le chapitre 8 est consacre a Spring Web Flow, un framework de gestion des flots Web, 
qui offre des mecanismes robustes afin de configurer et controler les enchainements de 
pages dans les applications Web. 

Le chapitre 9 aborde la technologie emergente AJAX, qui permet de mettre en oeuvre 
des applications Web riches possedant une interface graphique plus elaboree que 
celles des applications Web classiques. 

Le chapitre 10 clot cette partie en abordant le support portlet, qui permet de develop- 
per des applications de portail tout en reutilisant les principes de Spring MVC et les 
fonctionnalites de Spring. 
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Struts est certainement le framework de presentation le plus repute dans le monde J2EE. 
Cette notoriete le fait souvent demander dans les projets arm de respecter l'etat de l'art. 

En termes techniques, Struts est un framework MVC relativement elementaire. II gere 
des formulaires HTML et les actions des utilisateurs, mais ne va pas beaucoup plus loin. 
Cette simplicite fait aussi sa force : facile a prendre en main, il permet d'effectuer effica- 
cement les taches pour lesquelles il est concu. 

L'interet principal de Struts reside aussi dans le tres grand nombre de developpeurs qui 
connaissent son fonctionnement. Utiliser Struts sur un projet, c'est done s'assurer de ne 
pas avoir de problemes de ressources humaines. 

Ce framework est cependant vieillissant et se trouve aujourd'hui sous le feu des critiques. 
Nous verrons dans le cours de ce chapitre quels sont ses defauts et dans quelles situations 
Struts n'est plus la meilleure solution disponible. 

Une fois 1' architecture de Struts et ses principales classes explicitees, nous verrons de 
quelle maniere Spring integre Struts dans une application Java/J2EE, et a quelles fins. 
Cette integration pouvant etre realisee de trois manieres, nous etudierons chacune d'elles 
et degagerons leurs forces et faiblesses respectives. 

En fin de chapitre, nous detaillerons au travers de l'etude de cas Tudu Lists la configu- 
ration de Struts et de Spring, ainsi que le developpement d' actions et de formulaires 
specifiques. 
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Fonctionnement de Struts 



Cette section se penche sur 1' architecture interne de Struts et presente sa configuration et 
ses classes principales. 

Struts representant une implementation classique du framework MVC, il est important de 
commencer par rappeler brievement les caracteristiques de ce modele. 

Le pattern MVC (Model View Controller) 

Le pattern MVC est communement utilise dans les applications Java/J2EE pour realiser 
la couche de presentation des donnees aussi bien dans les applications Web que pour les 
clients lourds. Lorsqu'il est utilise dans le cadre de J2EE, il s'appuie generalement sur 
l'API servlet et des technologies telles que JSP/JSTL. 

II existe deux types de patterns MVC, le pattern MVC dit de type 1, qui possede un 
controleur par action, et le pattern MVC dit de type 2, plus recent, qui possede un contro- 
leur unique. Nous nous concentrerons sur ce dernier, puisque c'est celui sur lequel 
s'appuie Struts. 

La figure 6. 1 illustre les differentes entites du type 2 du pattern MVC ainsi que leurs interac- 
tions lors du traitement d'une requete. 



Controleur 



Front Controller 



Worker 




\ 



Aiguille les requetes vers le 
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\ 



V Realise le traitement de la 
requete. 



Modele 



Contient les donnees a 
presenter. 



Construit la vue en affichant 
les donnees a presenter. 



Vue 




Figure 6.1 

Composants du pattern MVC type 2 
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Les caracteristiques des composants de ce pattern sont les suivantes : 

• Modele. Permet de mettre a disposition les informations utilisees par la suite lors des 
traitements de presentation. Cette entire est independante des API techniques et est 
constitute uniquement de Beans Java. 

• Vue. Permet la presentation des donnees du modele. II existe plusieurs technologies de 
presentation, parmi lesquelles JSP/JSTL et XML, pouvant generer differents types 
de formats. 

• Controleur. Gere les interactions avec le client tout en declenchant les traitements 
appropries. Cette entire interagit directement avec les composants de la couche service 
metier et a pour responsabilite la recuperation des donnees mises a disposition dans le 
modele. Lors de la mise en oeuvre du type 2 de ce pattern, cette partie se compose d'un 
point d'entree unique pour toute l'application et de plusieurs entires de traitement. Ce 
point d'entree unique traite la requete et dirige les traitements vers l'entite Worker 
appropriee. Pour cette raison, l'entite Worker est habituellement appelee controleur. Le 
Front Controller, ou « controleur facade », est integre au framework MVC, et seuls les 
workers sont specifiques a l'application. 

Un framework MVC implemente le controleur facade, les mecanismes de gestion du 
modele ainsi que ceux de selection et de construction de la vue. L'utilisateur d'un tel 
framework a en charge le developpement et la configuration des workers. 



Architecture et concepts de Struts 

Comme explique precedemment, Struts est une implementation classique du framework 
MVC de type 2, dont les caracteristiques sont les suivantes : 

• Modele. Constitue de JavaBeans standards. Dans notre cas, ils proviennent des 
couches inferieures de l'application (couche de service ou couche de domaine). 

• Vue. Classiquement constitute de pages JSP. Cette partie peut aussi etre prise en 
charge par d'autres technologies de presentation, telles que Velocity (http:// 
jakarta.apache.org/velocity/) ou Cocoon (http://cocoon.apache.org/), tous deux de la fondaction 
Apache Jakarta. 

• Controleur. Constitue de la servlet Struts principale, appelee Acti onServl et. 

Dans son implementation, Struts utilise deux notions principales, qui sont representees 
par les classes org. apache, struts, acti on. Acti on, appelees actions, et 
org. apache. struts. action. ActionForm, appelees FormBeans, ou formulaires : 

• Action. Represente une action d'un utilisateur, telle que valider une selection, mettre 
un produit dans un panier electronique, payer en ligne, etc. Cette classe proche du 
controleur sert de liant entre le formulaire envoye par l'utilisateur, l'execution de trai- 
tements dans les couches metier de l'application et l'affichage d'une page Web resultant 
de l'operation. Elle represente le worker introduit a la section precedente. 
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• Formulaire. Represente un formulaire HTML, tel qu'il a ete rempli par l'utilisateur. 
Typiquement, ce formulaire a ete code en HTML avec des balises classiques de type 
<i nput type= '...'/>. Struts recoit et interprete en realite les parametres passes en GET 
ou en POST d'une requete HTTP. II est done possible de forger des URL, en Java- 
Script, par exemple, que Struts comprendra. Voici un exemple de paire cle/valeur 
passee en parametre d'une Action Struts : http://localhost:8080/example/test.do?clef=valeur. 

Lensemble forme par les actions, formulaires et JSP est relie via le fichier de configura- 
tion de Struts, struts-config.xml, lequel est generalement stocke dans le repertoire 
WEB-INF de 1' application Web. Dans le cas de Tudu Lists, ce fichier se trouve a 
1' emplacement WEB-INF/struts-config.xml. 



Configuration de Struts 

Struts se fonde sur une servlet tres evoluee pour assurer sa fonction de controleur generique. 
Comme pour toute servlet, il faut la configurer dans le fichier web.xml : 

( ... ) 
<servlet> 

<servl et-name>action</servlet-name> 

<servl et-cl ass> 
org. apache. st ruts. action. Act ionServlet 

</servl et-cl ass> 

<1 oad-on-startup>K/l oad-on- start up> 
</servlet> 
( ... ) 

<servlet-mapping> 

<servl et-name>action</servlet-name> 

<url -pattern>*.do</url -pattern> 
</servlet-mapping> 
( ... ) 

L'usage veut que Ton fasse correspondre les actions Struts a l'URL *.do, comme dans 
l'exemple ci-dessus. Cette extension en .do provient du verbe anglais to do (faire). Les 
actions Struts ont done toutes une URL se terminant en .do, par exemple, http://localhost/ 
example/test.do, de facon a etre renvoyees a ActionServlet, qui les traite. Comme il s'agit 
d'une convention de nommage arbitraire, pour Tudu Lists nous avons prefere sufhxer les 
actions par *. action, que nous trouvons plus parlant. 

ActionServlet, quant a elle, est configuree via le fichier struts-config.xml, que nous 
avons presente precedemment. Voici un exemple de ce fichier : 

<?xml version="1.0" encoding="UTF-8"?> 

<!D0CTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts 
^Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts- 
k»conf1g_l_l.dtd"> 
<struts-config> 
<form-beans> 
<form-bean 
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name="exampleForm" 
type=" tudu. web. form. Exampl eForm"/> 
</form-beans> 
<global-exceptions> 
<exception handler=" tudu. web. TuduExceptionHandler" 
key="error. general " 
path="/WEB-INF/jsp/error. jsp" 
type="java.lang.Throwable"/> 
</gl obal -exceptions> 
<gl obal -forwards> 

<forward name="error" path="/WEB-INF/jsp/error. jsp"/> 
</gl obal -forwards> 
<action-mappings> 
<action path="/test/example" 
name="exampl eForm" 

type="tudu. web. action . Exampl eAction" 
val idate="true"> 



<forward name="success" 

path="/WEB-INF/jsp/exampl e. jsp"/> 

</action> 
</action-mappings> 

<message- resources pa rameter="mes sages "/> 
</struts-config> 

Ce fichier XML comporte les grandes parties suivantes : 

• <form-beans>. Contient la liste des formulaires Struts. Nous donnons un nom a chaque 
formulaire, comme exampl eForm, ainsi que le nom de la classe Java a laquelle il corres- 
pond. II existe un type particulier de formulaire, dit DynaBean ou DynaForm, entierement 
decrit en XML. Tudu Lists est majoritairement constitue de DynaForms, mais nous 
conseillons dans un premier temps 1' utilisation de JavaBeans standards codes en Java. 
Presque aussi rapides a ecrire, ils sont moins sujets a erreur au debut. 

• <global -exceptions>. En fonction de leur type, les exceptions lancees par les actions 
sont renvoyees par Struts a des classes specifiques, qui doivent etre specifiquement 
implementees. Cette partie est facultative. 

• <global -forwards>. Donne des noms generiques a des pages JSP. Ces noms peuvent 
ensuite etre utilises depuis n'importe quelle action Struts. Dans notre exemple, nous 
pouvons renvoyer la page nommee erreur depuis toutes les actions, ce qui peut se 
reveler tres utile. Cette partie est egalement facultative. 

• <acti on-mappi ngs>. Cette partie est la plus importante et la plus complexe. Elle permet 
de Her une URL a une action. Dans notre exemple, nous utilisons l'URL /test/ 
example.action, en supposant que le suffixe Struts tel que decrit plus haut est .action. 
Toute requete envoyee a cette URL est traitee par la classe tudu . web .action. Exampl eActi on, 
si elle est validee par le formulaire exampl eForm. 

• <message-resources>. Definit un fichier de proprietes, dans notre cas messages .proper- 
ties. Situe a la racine du repertoire JavaSource de notre projet Eclipse, ce fichier 
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contient les messages utilises dans les pages JSP et les actions. Ce fichier est recherche 
a la racine du classpath (typiquement dans WEB-INF/classes). 

Ce fichier de configuration relativement complexe peut etre edite graphiquement. Struts 
etant un standard du marche, de nombreux IDE supportent son utilisation. C'est le cas 
notamment de JDeveloper d' Oracle, un IDE gratuit qui propose une configuration 
graphique assez intuitive. 

Si vous utilisez Eclipse, ou si vous n'utilisez pas d'IDE, nous vous conseillons l'utilisa- 
tion de Struts Console, un utilitaire gratuit tres bien concu disponible a l'adresse http:// 
www.jamesholmes.com/struts/console/index.html. 



Actions et formulaires 

Les actions et les formulaires sont les classes de base utilisees dans Struts. 

Les actions Struts heritent toutes de org. apache. struts. action. Action. Cette classe repre- 
sente une action standard, mais Struts est fourni avec un certain nombre d' actions plus 
evoluees, par exemple org. apache. struts. actions. DispatchActi on, lesquelles restent 
cependant proches dans leur fonctionnement. 

Voici un exemple d' action simple, provenant de Tudu Lists : 

package tudu. web; 

( ... ) 

/** 

* The Log out action. 
*/ 

public class LogoutAction extends Action { 

private final Log log = LogFactory.getLog(LogoutAction. class); 

public final ActionForward execute(ActionMapping mapping, 
ActionForm form, 

HttpServletRequest request, 
HttpServletResponse response) { 

log.debugC'Execute action"); 
request.getSession( ) .inval idate( ) ; 

Cookie terminate = new Cookie(TokenBasedRememberMeServices.ACEGI_SECURITY- 
*_HASHED_REMEMBER_ME_COOKIE_KEY , nul 1 ) ; 
terminate. setMaxAge(O) ; 
response. addCookie(terminate) ; 
return mapping. findForward( "logout") ; 

} 

} 
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Comme toutes les actions Struts, LogoutAction implemente la methode execute( ), laquelle 
prend quatre arguments : 

• mapping : correspond a la description faite precedemment dans le fichier struts- 
config.xml et permet de retrouver les vues telles quelles y ont ete decrites dans les 
balises <forward>. Si nous reprenons la configuration decrite precedemment, nous 
pouvons rediriger l'utilisateur vers la page d'erreur en faisant un mappi ng.fi nd- 
Forward( "error" ). 

• form : correspond au formulaire Struts, tel qu'il a ete decrit dans le fichier de configu- 
ration. Dans cet exemple tres simple, il n'y a pas de formulaire associe, ce qui est une 
configuration correcte. 

• request/response : correspondent aux objets classiques HttpServl etRequest et HttpServl et- 
Response, tels qu'ils existent pour les servlets. 

L'objectif de Taction est d'effectuer un traitement, generalement realise par la couche 
metier, avec un Bean Spring ou un EJB, par exemple, puis de renvoyer l'utilisateur vers 
une nouvelle page Web. Cette page est representee par l'objet Act i on Forward, que retourne 
Taction. 

Les formulaires Struts heritent tous de la classe org. apache. struts. action. ActionForm et 
sont des JavaBeans standards. 

II s'agit de formulaires HTML crees dans une page Web. Lors de la validation d'un 
formulaire, Struts transforme la requete HTTP envoyee en cet objet Java, que nos 
pouvons ensuite plus facilement manipuler. Chaque parametre de la requete HTTP est 
renseigne dans Tattribut du formulaire qui porte son nom. 

Par exemple, pour la requete HTTP suivante : 

http: //I ocal host/Tudu/exampl eAction.do?l i stld=001&name=test 

le formulaire ExampleForm a ses attributs listld et name renseignes (methodes setListld et 
setName), et nous pouvons acceder a ces valeurs via les methodes getListld et getName. 

II faut cependant etre conscient que ce formulaire est Texacte representation de ce qu'a 
envoye l'utilisateur via son navigateur et que les donnees qu'il contient ne sont done pas 
forcement valides. C'est pourquoi les formulaires Struts possedent une methode vali- 
date, qui est automatiquement appelee si, dans le fichier struts-config.xml, Tattribut 
val idate="true" est mis a une action donnee, ce qui est le cas dans Texemple de configu- 
ration ci-dessus. 

Voici un exemple de formulaire inspire de Tudu Lists : 
package tudu. web. form; 

( ... ) 



public class ExampleForm extends ActionForm { 
private String listld; 
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private String name; 

public ActionErrors val idate(ActionMapping mapping, HttpServletRequest request) { 

ActionErrors errors = new ActionErrorsC ) ; 
if (this.listld == null || this. listld. equalsC'")) { 
ActionMessage message = new ActionMessage( 
"errors . requi red" , "Todo List ID"); 

errors. add(ActionMessages.GLOBAL_MESSAGE, message) ; 

} 

if (this. name == null || this. name. equalst"")) { 
ActionMessage message = new ActionMessage( 
"errors . requi red" , "name); 

errors .add (Act ionMess ages .GLOBAL_MESSAGE, message) ; 

} 

return errors; 

} 

public String getListldO { 
return listld; 

} 

public void setListldtString listld) { 
this.listld = listld; 

} 

public String getNameO { 
return name; 

} 

public void setName(String name) { 
this. name = name; 

} 

} 

Dans cet exemple, la methode val i date force l'utilisateur a renseigner les champs listld 
et name de son formulaire. Sans cela, la requete HTTP envoyee n'atteindrait meme pas 
Taction. 



Les bibliotheques de tags 

Afin d' aider a l'affichage des pages JSP, Struts propose en standard les cinq bibliotheques de 
tags (tag libraries) suivantes : 

• Bean. Sert a afficher et manipuler des JavaBeans dans une JSP. Developpee avant 
l'existence des bibliotheques de tags standards, ou JSTL (JavaServer Pages Standard 
Tag Library), cette bibliotheque presente aujourd'hui peu d'interet. Rappelons que 
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depuis J2EE 1 .4, nous pouvons utiliser les JavaBeans directement dans les Pages JSP, 
de la maniere suivante : 

${todo.todoList.name} 

• HTML. D'excellente qualite, cette bibliotheque est l'une des raisons du succes de 
Struts. Tres proche dans sa syntaxe des elements de formulaire HTML, elle est intui- 
tive et permet de realiser facilement des formulaires Struts. Bien entendu, les formu- 
laires HTML peuvent toujours etre realises en HTML classique, Struts interpretant 
uniquement la requete HTTP envoy ee. Cette bibliotheque n'est done pas obligatoire 
mais fournit une aide interessante. 

• Logic. Sert a realiser des boucles et des branchements conditionnels. Comme la biblio- 
theque Bean, elle n'est plus d'actualite depuis l'apparition de JSTL. 

• Nested. Reprend 1' ensemble des bibliotheques Struts, en leur donnant la capacite de 
s'imbriquer les unes dans les autres. Cela simplifie considerablement l'utilisation 
d'arbres d'objets complexes. 

• Tiles. Permet 1' inclusion et le parametrage de fragments Tiles ( voir ci-apres). 

En resume, une grande partie des bibliotheques de tags de Struts ont ete detronees par 
JSTL. Reste principalement la bibliotheque HTML, qui permet de construire plus facile- 
ment des formulaires utilises avec Struts. En voici un exemple, issu d'une simplification 
de la page user_in.fo.jsp de Tudu Lists : 

<h3Xfmt: message key="user.info.title"/X/h3> 
<html:form action="/secure/myInfo" focus="f i rstName"> 

<c:if test="$(success eq 'true')"> 
<span class="success"Xfnit:message key="form.success"/X/span> 

</c:if> 

<html :errors/> 
<hr/> 

<fmt:message key="user. info. first. name"/> : 
<html:text property="f i rstName" size="15" maxl ength="60"/> 
<br/> 

<fmt:message key="user. info. last. name"/> : 
<html:text property="l astName" size="15" maxl ength="60"/> 
<br/> 

<fmt:message key="user. info. email "/> ; 
<html:text property="emai 1 " size="30" maxl ength="100"/> 
<hr/> 

<html :submit> 
<fmt: message key="form.submi t"/> 
</html : submit> 

<html :submit><fmt:message key="form. cancel "/X/html :submit> 
</html :form> 
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La technologie Tiles 

Tiles est une technologie de decoupage de pages JSP qui s'appuie sur les i ncl ude des JSP en 
les ameliorant significativement. En particulier, Tiles permet d'effectuer les taches suivantes : 

• Creer aisement des modeles de pages reutilisables, avec un support de l'heritage entre 
differents modeles. 

• Nommer les pages au lieu de donner leur chemin complet, dans l'esprit des tags 
<forward> vus precedemment dans la configuration de Struts. 

• Reutiliser des composants de presentation, y compris des composants internationalises 
(nous n'affichons pas le meme composant suivant la langue de l'utilisateur). 

II y a done de grandes chances pour que vous souhaitiez mettre Tiles en oeuvre dans vos 
projets, d'autant plus que ce n'est guere complique. 

Tiles fait partie integrante du code source de Struts, bien qu'il s'agisse d'un composant 
optionnel, qui n'est pas active par defaut. Pour l'activer, il suffit d'ajouter les lignes 
suivantes a la fin du fichier struts-config.xml (juste avant la balise de fermeture </struts- 
config>) : 

<pl ug-i n className= 

"org. apache. st ruts. t i 1 es. Tiles PI ugin"> 

<set-property property= 

"definitions-config" 
val ue="/WEB-INF/ti 1 es-defs.xml "/> 
</pl ug-i n> 

II suffit ensuite de creer le fichier tiles-def.xml dans le repertoire WEB-INF. Voici un 
exemple de ce fichier, dans lequel nous definissons un modele simple (layout) et deux 
pages qui en heritent : 

<?xml version="1.0" encoding="IS0-8859-l"?> 

<!D0CTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD 
*Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/ 
*»til es-conf ig_l_l .dtd"> 

<tiles-definitions> 
<definition name="l ayout" path="/WEB-INF/jsp/l ayout. jsp"> 

<put name="title" value="Titre par defaut" /> 

<put name="body" /> 
</definition> 

definition name="index" extends="l ayout"> 

<put name="body" val ue="/WEB-INF/jsp/index. jsp" /> 

<put name="title" val ue="Bienvenue" /> 
</definition> 

<definition name="user" extends="l ayout"> 

<put name="body" val ue="/WEB-INF/jsp/user. jsp" /> 

<put name="title" val ue="Gestion des uti 1 i sateurs" /> 
</definition> 
</tiles-definitions> 
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Pour utiliser ces composants dans Struts, il faut modifier les <forward> dans struts- 
config.xml. Dans l'exemple precedent, pour rediriger vers le composant index, il faut 
mettre dans la configuration de Taction : 

<forward name="success" path="index"/> 

Nous utilisons comme chemin (path) le nom de la definition Tiles configured dans le 
fichier tiles-def.xml. Bien entendu, nous pouvons toujours utiliser des pages JSP classi- 
ques a la place de Tiles. En effet, a chaque forward, Struts verifie si une definition Tiles 
correspond au chemin demande. S'il n'en trouve pas, il bascule en fonctionnement 
normal et peut alors rediriger vers une JSP classique. 



Points faibles et problemes lies a Struts 

Struts a ete le premier framework MVC a rencontrer un fort succes aupres de la commu- 
naute Java. Depuis sa creation, fin 2000, ce framework a cependant relativement mal 
vieilli, et un certain nombre de problemes sont apparus, notamment les suivants : 

• Trap grande adherence avec les classes HttpServl etRequest et HttpServl etResponse, qui 
sont passees en parametre de la methode execute des actions. Cela limite Struts a etre 
utilise avec des servlets et des pages JSP, si bien qu'il est impossible de reutiliser une 
couche Struts dans un client Swing. 

• Utilisation de classes concretes, et non d'interfaces, ce qui limite considerablement la 
possibility de tester des actions Struts. En particulier, il est impossible d'utiliser des 
simulacres d'objets, ou mock objects, pour tester des actions Struts. 

• Absence de mecanisme standard d' interception des actions. Une chaine d'interception 
permettrait, par exemple, de gerer le logging, la securite ou l'ouverture des acces en 
base de donnees dans des objets specialises et transversaux aux actions. 

• Erreurs de typage dans les formulaires, qui lancent des exceptions techniques criti- 
ques. Au final, les seuls attributs reellement utilisables pour les formulaires sont de 
type String. Cela ajoute un niveau de conversion avec les objets metier d'une 
complexite inutile. 

• Prise en compte des seules donnees envoyees par les formulaires. Les donnees de refe- 
rence, par exemple une liste a selectionner, doivent etre traitees separement et mises en 
attribut de requete ou de session, de la meme maniere qu'avec les servlets. Cela lie 
encore plus le controleur a une couche de presentation codee en JSP. 

• Necessite, pour la bibliotheque de tags HTML, d'utiliser un editeur de JSP supportant 
Struts. Sa maniere de fonctionner l'empeche en effet d'etre comprise par des editeurs 
HTML couramment utilises, tels que DreamWeaver. 

• Separation entre actions et formulaires peu justifiee, qui augmente le nombre de 
classes et de lignes a ecrire. 

• Absence de mecanisme d' acces a une couche metier. Dans la pratique, les actions 
Struts sont forcees d'aller elles-memes se connecter a la couche metier, par exemple en 
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utilisant JNDI dans le cadre d'une couche metier codee en EJB. Cela presente les 
inconvenients supplementaires suivants : 

- Gene encore plus la testability des actions, puisqu'il est impossible d'executer un 
test JUnit si l'objet teste appelle un EJB dans ses methodes. 

- Lie les actions Struts a une implementation de la couche metier et non a des interfaces. 

- Limite l'utilisation de fonctionnalites avancees lors de l'acces a la couche metier, 
comme des proxy dynamiques ou de la POA pour gerer les transactions. 

Ces desavantages, minimes au debut de la vie de Struts, sont devenus aujourd'hui plus 
visibles : de nouveaux frameworks, mieux concus, ont mis en lumiere ces manquements. 
Citons parmi eux Spring MVC, que nous presentons au chapitre suivant, mais aussi 
Tapestry ou Web Work, avec lequel Struts est destine a fusionner depuis fin 2005. 

Struts et JSF (Java Server Faces) 

JSF est l'API standard (JSR 127 du Java Community Process) d'affichage des compo- 
sants dans des pages Web. II ne s'agit pas d'un concurrent direct de Struts, puisqu'il se 
preoccupe uniquement de la partie presentation. Par ailleurs, rien n'empeche d'utiliser 
Struts en tant que controleur, au sens MVC, de 1' application. II n'y a done rien de surpre- 
nant a la bonne integration de ces deux technologies, qui sont de surcroit l'oeuvre d'un 
meme homme, Craig McClanahan. 

JSF est davantage concurrent de la bibliotheque de tags HTML de Struts, mais rien 
n'empeche d'utiliser ces deux technologies conjointement. 

Concernant l'avenir de Struts, il est certain que sa tres grande popularite lui vaudra de 
rester encore longtemps d'actualite. Lun des objectifs de l'equipe qui l'a developpe a 
toujours ete d'assurer une bonne compatibility entre les versions. C'est pourquoi elle a 
prefere une API stable a une evolution vers des concepts plus modernes. Dans la pratique, le 
succes de Struts lui a donne raison. 

Cependant, Struts pourrait etre detrone a long terme par plusieurs autres technologies, 
notamment les suivantes : 

• Shale. Nouvelle version de Struts, toujours developpee par la fondation Apache et 
Craig McClanahan, resolvant la majorite des problemes souleves a l'encontre de 
Struts. Ne semble pas avoir encore provoque d'engouement particulier. 

• Spring MVC. Excellente implementation du pattern MVC, entierement integree a Spring. 

• AJAX. Technique de codage d'une page Web tres en vogue utilisant JavaScript pour 
charger a la demande des morceaux d' information inseres a chaud dans la page en cours. 
Tudu Lists en fait une utilisation intensive pour gerer les listes de todos et les todos eux- 
memes, et nous la presentons en detail au chapitre 9. Struts est mal adapte a ce type de 
programmation, qui possede ses propres frameworks, comme DWR, que nous presentons 
egalement au chapitre 9. Utilise dans Tudu Lists, ce dernier permet d'utiliser directement 
des Beans Spring en JavaScript, ce qui court-circuite completement Struts. 
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En resume 

Bien que toujours tres populaire, Struts est un framework vieillissant. Parmi les 
nombreuses solutions de rechange plus evoluees techniquement disponibles sur le 
marche, citons Spring MVC, Tapestry ou Web Work. 

Ces solutions ont en commun d'etre fondees sur des conteneurs legers et de proposer des 
mecanismes d' interception. Nous verrons dans les sections qui suivent qu'en couplant 
Spring et Struts, il est possible d'obtenir les memes avantages. 

Integration de Struts a Spring 

Bien que Spring possede son propre framework MVC, il s'integre parfaitement avec Struts. 

Nous verrons dans cette section de quelle maniere cette integration est realisee et tente- 
rons de degager les benefices que nous pouvons en retirer, en particulier du point de vue 
des utilisateurs de Struts. 

Interet de /'integration de Struts a Spring 

L'interet de l'integration de Struts a Spring est d'ajouter a Struts un acces performant a la 
couche metier de 1' application, Spring se chargeant de gerer la couche metier. Ce faisant, 
les actions Struts ne sont plus liees a des implementations d'objets metier mais a leurs 
interfaces. Toutes les fonctionnalites de Spring sont disponibles lors de l'acces a cette 
couche metier, notamment 1' utilisation de la POA pour gerer les transactions. 

Spring vient ainsi combler une importante lacune de Struts, contribuant a moderniser ce 
framework. 

Cette integration est disponible sous trois formes differentes, chacune ayant ses avantages et 
ses inconvenients. Les sections qui suivent passent en revue chacune d'elles. 

Configuration commune 

Quel que soit le type d'integration choisi, il faut tout d'abord ajouter un contexte Spring 
a Struts. II s'agit en realite d'un sous-contexte du contexte Spring general, qui se charge 
en tant que plug-in Struts. 

Pour cela, il faut ajouter les lignes suivantes dans le fichier struts-config.xml : 

<plug-in cl assName=" org. spring-framework, web. struts. Context Loader PI ugln"> 

<set-property property =" con textConfig Location" 

val ue="/WEB-INF/action-servl et .xml "/> 

</pl ug-in> 

Cette configuration provient de Tudu Lists, qui fournit un exemple d'integration de 
Spring et de Struts. Habituellement, ce fichier de configuration Spring est nomme action- 
servlet.xml. 
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Utilisation d'ActionSupport 

La maniere la plus simple de connecter Struts a Spring consiste a utiliser la classe 
org. springframework. web. struts. ActionSupport. II suffit pour cela de faire heriter ses 
actions de ActionSupport au lieu de org. apache. struts. action. Action. 

L' action Struts en cours herite alors de la methode getwebAppl icationContext, qui permet 
d'acceder au contexte d' application Spring configure precedemment (en tant que plug-in 
Struts) : 

package tudu.web; 
( ... ) 

/** Backup a Todo List. */ 
public class BackupTodoListAction 

extends org. springframework. web. struts. ActionSupport { 

public final ActionForward execute( 
ActionMapping mapping, ActionForm form, 

HttpServletRequest request, HttpServl etResponse response) 
throws Exception { 

DynaActionForm todoListForm = (DynaActionForm) form; 
String listld = (String) todoListForm. getC'listld") ; 
ApplicationContext ctx = getWebAppl i cationContext( ) ; 
TodoLi stsManager todoListsManager = 
(TodoListsManager) ctx.getBean( "todoListsManager" ) ; 
TodoList todoList = todoListsManager. f i ndTodoLi st ( 1 i st Id ) ; 
Document doc = todoListsManager. backupTodoList(todoList); 
request. getSession( ) 
. setAttribute( "todo Li st Document" , doc) ; 
return mapping. findForward( "backup" ) ; 

} 

} 

Dans cet exemple, nous recherchons le Bean Spring todoListsManager dans le contexte 
Spring. 

Spring propose des equivalents plus evolues des actions Struts, comme DispatchAction 
(DispathActionSupport). Le code reste proche de celui d'une action Struts classique et est 
simple a mettre en oeuvre dans une application existante. II ne permet toutefois pas de 
beneficier pleinement des capacites de Spring au niveau de la couche MVC, comme 
l'inversion de controle pour injecter des Beans metier dans les actions. Pour cette raison, 
ce n'est pas la methode que nous recommandons, en depit de sa facilite d'utilisation 
attrayante. 
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Le DelegationRequestProcessor 

Changer le RequestProcessor de Struts permet de decoupler les actions Struts de Spring. II 
n'y a done plus d'import de classes Spring dans les actions, et les actions Struts devien- 
nent de veritables Beans Spring, qui beneficient de toute la puissance de ce framework 
(injection de dependances, POA, etc.). 

Pour changer le RequestProcessor, il faut ajouter un element dans le fichier struts- 
config.properties, entre l'element <message-resources> et l'element <plug-in> : 

<control ler processorClass=" org. springframework. web. struts. 
Del egatingRequestProcessor"/> 

Une action Struts doit etre definie en tant qu' action dans le fichier struts-config.properties 
et en tant que Bean Spring dans le fichier action-servlet.xml. 

Dans struts-config.properties : 

<action path="/secure/backupTodoList" 
name= " todoLi st Form" 
type="tudu.web.BackupTodoListAction"> 

</action> 

Dans action-servlet.xml : 

<bean name="/secure/backupTodoList" 
cl ass="tudu.web.BackupTodoListAction"> 

<property name="todoListsManager"> 
<ref bean="todoLi stsManager" /> 
</property> 
</bean> 

Notons que le nom du chemin (path) Struts est identique a celui du Bean Spring. 

L' action vue precedemment beneficie maintenant de 1' inversion de controle et peut etre 
reecrite ainsi : 

package tudu.web; 
( ... ) 

/** Backup a Todo List. */ 
public class BackupTodoListAction 

extends org. apache. struts. action. Action { 

private TodoLi stsManager todoLi stsManager = null; 

public final void setTodoLi stsManager( 
TodoLi stsManager todoListsManager) { 



this.todoListsManager = todoListsManager; 

} 
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public final ActionForward execute( 
ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServl etResponse response) 
throws Exception { 

DynaActionForm todoLi stForm = (DynaActionForm) form; 

String listld = (String) todoListForm.getC'listld") ; 

TodoList todoList = todoListsManager.findTodoList(listld); 

Document doc = todoListsManager.backupTodoList(todoList); 

request. getSession( ) 

. setAttribute( "todoLi st Document" , doc) ; 

return mapping. findForward( "backup" ) ; 

} 

} 

La seule faiblesse de cette methode est d'utiliser un RequestProcessor specifique. Cela 
pose des problemes aux applications qui utilisent leur propre RequestProcessor, une technique 
couramment utilisee pour etendre Struts. 

Ainsi, pour l'utilisation de Tiles, qui utilise lui aussi son propre RequestProcessor, une classe 
Del egati ngTi 1 esRequestProcessor est fournie par Spring. Mais cet exemple met en lumiere la 
necessite de coder des RequestProcessor tres specifiques afin de lier Struts et Spring. 



La delegation d'actions 

La delegation d'actions est la methode que nous conseillons et que nous utilisons avec 
Tudu Lists. 

Proche de la methode precedente, elle permet de gerer les actions Struts depuis Spring 
comme des JavaBeans, mais sans impact sur la configuration de Struts. L'idee est d'utili- 
ser une classe specifique, org. springframework. web. struts. DelegatingActionProxy, afin de 
deleguer la gestion de Taction Struts a Spring. 

Dans la pratique, nous continuons a coder des actions Struts normalement (ces classes 
peuvent meme heriter d'actions complexes, comme les DispatchAction). La seule diffe- 
rence est que, dans struts-config.xml, nous donnons org. springframework. web. struts. Dele- 
gatingActionProxy comme etant la classe de Taction. 

Par exemple, dans Tudu Lists, Taction "/regi ster" est configured de la facon suivante : 

<actionpath='7 register" 
name="registerForm" 

type=" org. springframework. web. st ruts. DelegatingActionProxy" 

parameter="method" 

val idate="fal se" 

input="/WEB-INF/jsp/register . jsp"> 



<forward name=" regi ster" path="/WEB-INF/jsp/regi ster. jsp"/> 
<forward name=" success" path="/WEB-INF/jsp/register_ok. jsp"/> 

<forward name="cancel " path="/welcome. action" redi rect="true"/> 
</action> 
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Dans le fichier de configuration Spring action-servlet.xml, cette action est configuree de 
la facon suivante : 

<bean name="/register" class="tudu.web.RegisterAction"> 

<property name="userManager"> 
<ref bean="userManager" /> 

</property> 
</bean> 

Spring realise le lien avec Taction Struts via le nom du Bean, identique au chemin de 
Taction Struts "/register". 

De meme que pour la methode precedente, RegisterAction est a la fois une action Struts 
complete, qui herite de DispatchAction, et un Bean Spring a part entiere, beneficiant de 
Tinversion de controle. 



En resume 

II est relativement facile d'integrer Struts et Spring et de combiner ainsi les avantages de 
chaque framework : 

• Struts apporte une couche MVC simple et bien connue des developpeurs. 

• Spring apporte un acces simple et non intrusif a une couche metier performante. 

Nous avons vu qu'il etait possible d' avoir des classes etant a la fois des actions Struts et 
des Beans Spring. Ces « nouvelles actions Struts » ont des capacites bien superieures aux 
actions classiques, reduisant ainsi les faiblesses de Struts. 

Grace a la delegation d' actions, ces nouvelles classes beneficient des avantages suivants : 

• Elles ne lient plus la couche de presentation a une implementation donnee de la couche 
metier. 

• Elles sont plus facilement testables de maniere unitaire du point de vue de T acces a la 
couche de service. Elles dependent toutefois toujours des API servlet et Struts et 
restent done difficiles a tester. 

• Elles disposent d'un mecanisme d' interception. Ces classes etant des Beans Spring, 
nous pouvons utiliser la POA pour intercepter leurs methodes. Cela peut permettre 
d'ajouter des mecanismes transversaux de securite, de monitoring, de logging, de 
cache, etc. 



Tudu Lists : integration de Struts 

Reprenant notre etude de cas Tudu Lists, nous allons mettre en pratique Tintegration de 
Spring et de Struts en utilisant la delegation d'actions. 

Pour Tudu Lists, nous avons fait le choix d'une couche de presentation MVC avec Struts, 
enrichie de Tintegration avec Spring. Malgre ses defauts, nous avons prefere utiliser 
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Struts en standard avec Tudu Lists en raison de sa tres large diffusion et parce que nous 
en connaissons bien les rouages. 

Pour cette application particuliere, nous n'avons pas besoin d'une couche de presentation 
tres elaboree, capable, par exemple, de gerer des workflows complexes. Si cela avait ete 
le cas, nous aurions opte pour l'utilisation conjointe de Struts et d'une technologie plus 
adaptee, par exemple Spring Web Flow. 

Concernant la partie vue de l'application, nous avons choisi d'utiliser des pages JSP dans 
le cas general, en utilisant au maximum la JSTL (JavaServer Pages Standard Tag 
Library). Nous utilisons aussi les nouvelles notations apportees par J2EE 1.4, de type 
${javabean.attribut}, ce quireduit et clarifie considerablement le code. Dans certains cas 
tres particuliers, nous avons utilise des servlets : c'est le cas de la generation de flux RSS. 
Ce flux etant genere par Rome, un framework Open Source specialise dans la gestion de 
ce type de flux, l'utilisation d'une JSP n'a pas d'interet. 

Tudu Lists utilise aussi la technologie AJAX (Asynchronous Javascript And XML), qui 
permet de communiquer en XML avec le serveur sans recharger la page Web en cours. 
Une partie de la couche de presentation a done ete realisee avec DWR, un framework 
permettant d'utiliser des Beans Spring cote serveur directement en JavaScript cote client. 
Cette technique est detaillee au chapitre 9, dedie a AJAX. 

Les fichiers de configuration 

La configuration de la partie presentation de Tudu Lists est repartie dans les fichiers 
suivants : 

• WEB-INF/web.xml. Fichier standard de configuration des applications Web J2EE 
servant ici a configurer la servlet ActionServl et de Struts. 

• WEB-INF/struts-config.xml. Fichier de configuration de Struts que nous avons 
etudie precedemment. Tudu Lists utilisant la delegation d'actions, l'ensemble des 
actions decrites dans ce fichier est de type org. springf ramework. web. struts. Delegatin- 
gActionProxy. Ann de limiter le nombre de formulaires Struts, nous utilisons des Dyna- 
Form. Uniquement decrits en XML dans le fichier struts-config.xml, ces formulaires 
n'ont pas d'implementation Java. 

• WEB-INF/validation.xml. Fichier de configuration du Validator de Struts. Ce dernier 
est un plug-in Struts aidant a la validation de formulaires en fournissant des implemen- 
tations Java et JavaScript des principales regies de validation trouvees dans une appli- 
cation Web (champ obligatoire, tailles minimale et maximale, champ e-mail, etc.). 

• WEB-INF/validator-rules.xml. Fichier de configuration interne du Validator, n' ayant 
normalement pas a etre modifie. 

• WEB-INF/action-servlet.xml. Fichier contenant une configuration Spring standard, 
dans laquelle les actions Struts sont definies en tant que Beans Spring. Cela permet de 
configurer 1' injection de dependances dont elles beneficient. 
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JavaSource/messages.properties. Fichier stockant les messages utilises dans 1' appli- 
cation. II s'agit d'un fichier de proprietes, aussi appele resource bundle, permettant de 
gerer plusieurs langues. 



Exemple d'action Struts avec injection de dependances 

Pour cet exemple, nous allons utiliser tudu.web.MylnfoAction, une action qui permet a 
l'utilisateur de gerer ses informations personnelles. 

Lors de l'utilisation de cette action, le parcours de l'utilisateur est le suivant : 

1. L'utilisateur execute Taction MylnfoAction sans lui envoyer de parametre. 

2. Les informations concernant l'utilisateur en cours sont recherchees en base de 
donnees. 

3. La page WEB-INF/jsp/user_info.jsp est affichee. Elle contient les informations 
recuperees precedemment, pretes a etre modifiees. 

4. L'utilisateur modifie ces informations. II peut ensuite soit annuler ses changements 
(retour a l'etape 1), soit les valider et passer a l'etape 5. 

5. Si les informations envoyees ne sont pas correctes, l'utilisateur est renvoye a 
l'etape 3. 

6. Les informations sont sauvegardees en base de donnees, et nous revenons a l'etape 1. 

La classe MylnfoAction est un groupement de trois actions differentes : l'affichage de la 
page, l'annulation du formulaire et sa validation. 

Dans les premieres versions de Struts, il fallait trois classes differentes pour representer 
ces trois actions, ce qui obligeait a ecrire beaucoup de code. C'est desormais simplifie 
grace a la classe org. apache. struts. actions. DispatchActi on, dont MylnfoAction herite via 
tudu.web.TuduDi spatchAction. 

Ainsi, MylnfoAction est plus un groupe d'actions qu'une action, ce qui a pour effet de 
reduire le nombre de classes et la taille du fichier de configuration. 

La signature de ses methodes est la suivante : 

package tudu.web; 

( ... ) 

public class MylnfoAction extends TuduDispatchAction { 

public final void setUserManager(UserManager userManager) { 
( ... ) 

} 

public final ActionForward display( 

ActionMapping mapping, ActionForm form, 

HttpServl etRequest request, HttpServletResponse response) { 
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( ... ) 
} 

public final ActionForward update( 

ActionMapping mapping, ActionForm form, 

HttpServletRequest request, HttpServl etResponse response) { 

( ... ) 

} 

} 

La premiere methode, setUserManager, est utilisee pour l'injection de dependances avec 
Spring. 

Les deux autres methodes, di spl ay et update, correspondent aux actions Struts dont nous 
avons precedemment parle, qui servent a africher et a mettre a jour les informations utili- 
sateur. II existe egalement une methode cancel, dont MylnfoAction herite, qui correspond 
a l'annulation de Taction. En realite, cette methode ne fait que rediriger vers la methode 
di spl ay. En effet, une annulation effectue un nouvel affichage de la page initiale, avec les 
donnees d'origine. 

Ces actions sont configurees via le fichier struts-config.xml : 

<form-bean name="userForiri" 

type=" org. apache. st ruts, val idator.DynaVal idatorForm"> 

<form-property name="password" type="java.lang.String"/> 

<form-property name=" verify Password" type="java .1 ang. St ring'/Xform- property 

*»name="f i rstName" type=" java .1 ang.String"/> 

<form-property name="l astName" type="java.lang.String"/> 

<form-property name="emai 1 " type="java.lang.String"/> 

</form-bean> 

( ... ) 

<action 

pat h=" /secure/my Info" 
name="userForm" 

type="org.springf ramework. web. struts. Del egatingActionProxy" 

parameter="method" 

val idate="fal se" 

input="/WEB-INF/jsp/user_info. jsp"> 

<forward name=" user. info" path="/WEB-INF/jsp/user_info. jsp"/> 
</action> 

MylnfoAction peut executer chacune des methodes display, update et cancel en fonction 
d'un parametre qui lui est envoye. Ce parametre, configure plus haut en tant qu'attribut 
de Taction, est defini a "method". Cela signifie qu'un parametre HTTP "method" va etre 
envoye avec le formulaire et qu'en fonction de ce parametre une methode sera executee. 
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On retrouve ce parametre dans la page JSP WEB-INF/jsp/user_info.jsp (le code suivant 
est volontairement simplifie afin de mettre en valeur l'essentiel) : 

<html:form action="/secure/myInfo" focus="f i rstName"> 
<html :errors/> 

<html : hidden property="method" val ue="cancel "/> 

<fmt: message key =" user. info.fi rst.name"/> 

<html:text property="f i rstName" size="15" maxl ength="60"/> 

<br/> 

<fmt: message key =" user. info. last. name "/> 

<html:text property="l astName" size="15" maxlength="60"/> 

<br/> 

<fmt:message key="user. info. email "/> 

<html:text property="email " size="30" maxl ength="100"/> 

<br/> 

<fmt: message key =" user. info. pas sword "/> 

<html :password property="password" size="15" maxlength="32"/> 
<br/> 

<html :submit 

onclick="document.forms[0]. elements ['method']. valuer 'update' ;"> 

<fmt: message key =" form. submit "/> 
</html :submit> 

<html :submit><fmt:message key="form. cancel "/></html :submit> 
</html :form> 

L'utilisation du champ HTML "method", qui est un champ cache, ainsi que celle de Java- 
Script dans l'evenement "onClick" du bouton "Submit", permettent d'envoyer avec le 
formulaire une variable supplementaire. 

L'envoi du formulaire permet ainsi d'envoyer les variables "fi rstName", "1 astName", 
"email", "password" et "method". C'est cette derniere variable qui sera utilisee par Struts 
pour determiner quelle methode utiliser dans MylnfoAction. 

Integration de Spring et de Struts 

Dans le fichier struts-config.xml, Taction est configuree en tant que DelegatingAc- 
tionProxy. Nous utilisons done la troisieme forme d'integration Struts-Spring presentee 
precedemment, a savoir la delegation d' actions. 

Nous retrouvons par consequent le JavaBean MylnfoAction configure dans le fichier 
WEB-INF/action-servlet.xml : 

<bean name="/secure/myInfo" class="tudu.web.MyInfoAction"> 
<property name="userManager"> 
<ref bean="userManager" /> 
</property> 
</bean> 
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Grace a cette configuration, le JavaBean userManager est injecte dans MylnfoAction. Nous 
pouvons l'utiliser directement dans MylnfoAction, par exemple dans la methode displ ay : 

public final ActionForward display( 

ActionMapping mapping, ActionForm form, 

HttpServletRequest request, HttpServl etResponse response) { 

log.debugC'Execute display action"); 
String login = request. getRemoteUsert ) ; 
User user = userManager. findUser(login) ; 
DynaActionForm userForm = (DynaActionForm) form; 
user Form. set ( "password" , user. get Password ( ) ) ; 
userForm. sett "verify Password" , user .get Password ( ) ) ; 
userForm. sett "fi rstName" , user .get Fi rstNamet ) ) ; 
userForm. sett "1 as t Name" , user. get Last Name ( ) ) ; 
userForm. sett "emai 1 " , user .get Emai 1 ( ) ) ; 
return mapping. findForwardC'user. info") ; 

} 

Dans cet exemple, nous avons done bien une action Struts complete relativement evoluee, 
notamment grace a l'utilisation de DispatchAction, qui s'integre parfaitement dans Spring 
en tant que JavaBean standard et beneficie ainsi de l'injection de dependances. 



Utilisation conjointe des DynaBeans et du Validator 

Tudu Lists utilise deux fonctionnalites avancees de Struts que nous n' avons pas encore 
detaillees, les DynaBeans et le Validator. Utilisees conjointement, elles reduisent la 
complexite de l'application en supprimant la majeure partie du code necessaire au codage 
des formulaires. 

Coder des formulaires Struts devient rapidement repetitif puisque nous nous retrouvons 
avec un grand nombre de JavaBeans qui n'ont pas grande utilite. De plus, la validation de 
ces formulaires est fastidieuse, car il faut chaque fois coder la methode validatet) des 
formulaires, un travail le plus souvent long, meme pour un resultat simple. 

Voici un exemple de methode val idatet ) qui teste si un champ obligatoire a ete rensei- 
gne : 

public ActionErrors validatet 

ActionMapping mapping, HttpServletRequest request) { 

ActionErrors errors = new ActionErrorst ) ; 
if (this.todold == null || this.todold.equalst"")) { 
ActionMessage message = new ActionMessaget 

"errors . requi red" , "Todo ID"); 

errors. add ( Act ionMess ages. GLOBAL_MESSAGE, message) ; 

} 

return errors; 
} 
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Ce code est incomplet, car il ne represente qu'une validation cote serveur, alors que bien 
souvent une validation cote client en JavaScript est necessaire afin de ne pas surcharger le 
serveur de requetes contenant des informations potentiellement non valides. 

Les formulaires Struts se revelant longs et repetitifs a coder, les DynaBeans et le Validator 
ont ete concus pour soulager le developpeur. 

Un DynaBean est un formulaire Struts decrit uniquement en XML dans le fichier struts- 
config.xml. Nous en avons deja rencontre un dans le code decrivant le formulaire user- 
Form : 

<form-bean name="userForm" 

type= "org. apache. struts.val i dator.Dyna Validator Form" > 

<form-property name="password" type="java.lang.String"/> 

<form- property name=" verify Password" ty pe=" j a va.lang. St ring'VXform- property 

name="fi rstName" type=" j a va.lang. St ring"/> 

<form-property name="l astName" type="java.lang.String"/> 

<form-property name="email " type="java.lang.String"/> 

</form-bean> 

Malheureusement, une des limitations de Struts vient de ce que le type des proprietes des 
DynaBeans est presque obligatoirement java.lang. String. Struts renvoie des erreurs 
fatales en cas de non-correspondance entre une propriete envoyee par le navigateur client 
et son type. 

Le Validator permet quant a lui de valider automatiquement le formulaire cote serveur 
comme cote client. 

Cette validation est definie dans le fichier WEB-INF/validation.xml : 

<form name="userForm"> 

<f i el d property="password" depends="requi red"> 

<argO key="user. info. password" /> 
</field> 

<field property="verifyPassword" depends="validwhen"> 
<argO key="user. info. password. not. matching" /> 
<var> 

<var-name>test</var-name> 
<var-value>(*this* == password)</var-val ue> 
</var> 
</field> 

<field property="fi rstName" depends="requi red"> 

<argO key="user. info. first. name" /> 
</field> 

<f i el d property="l astName" depends="requi red"> 

<argO key="user. info. last. name" /> 
</field> 

<field property="email " depends="email "> 

<argO key="user. info. email " /> 
</field> 
</form> 
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Dans cet exemple, nous pouvons definir des champs comme "required" (obligatoire), 
"validwhen" (valable en fonction d'un test) ou "email" (s'il s'agit d'un e-mail valide). Un 
certain nombre de validations standards, en particulier sur le type et la taille des champs, 
sont en outre configurees dans le fichier WEB-INF/validator-rules.xml. II est bien 
entendu possible d'ajouter des validations supplementaires, mais Struts fournit par defaut 
une bibliotheque de regies de validation assez complete. 

Cette validation fonctionne automatiquement cote serveur et peut etre ajoutee cote client 
en inserant simplement le tag suivant dans la page JSP de formulaire : 

<html :javascript formName="userForm"/> 

L'ajout de ce tag permet de generer a la volee le JavaScript necessaire a la validation du 
formulaire passe en parametre. 

Dans Tudu Lists, nous utilisons cette double technique des DynaBeans et du Validator 
afin de reduire la taille du code a ecrire et realiser 1' application le plus rapidement 
possible. 

Cette solution n'est toutefois pas a recommander dans tous les cas, notamment pour les 
raisons suivantes : 

• Le temps de codage des formulaires n'est pas toujours tres long. Par exemple, coder un 
JavaBean avec Eclipse est tres rapide, en particulier grace au menu Source/Generate 
Getters and Setters. 

• Les DynaBeans font perdre la garantie de la compilation et ne permettent plus 
d'utiliser les fonctionnalites de refactoring d'Eclipse pour renommer un champ. 

• Tres utile pour les validations simples, le Validator devient soit trop complexe pour les 
validations plus avancees (plus simples a realiser en Java), soit completement ineffi- 
cace pour les validations metier (qui necessitent de toute maniere d'etre executees au 
niveau de Taction). 

Dans une application, la technique decrite precedemment n'est valable que pour les 
formulaires simples, pour lesquels elle apporte des gains de temps et de taille de code. 

Dans le cas particulier de Tudu Lists, la majorite des formulaires est assez simple. II 
s'agit soit de pages aux fonctionnalites elementaires (comme Taction MylnfoAction), soit 
de pages plus complexes dans lesquelles les fonctionnalites avancees sont deportees dans 
la couche AJAX. 



Creation d'un intercepteur sur les actions Struts 

Outre Tinjection de dependances, Tun des interets d'integrer Spring et Struts est d'utiliser 
des intercepteurs Spring sur les actions Struts. 

Pour cet exemple, nous allons utiliser Tun des intercepteurs fourni en standard avec 
Spring, org. spring-framework, aop. interceptor . Debug Interceptor. 
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Cet intercepteur est configure dans le fichier WEB-INF/action-servlet.xml : 

<bean id="debugInterceptor" 
cl a ss= " org. springf ramework.aop. interceptor. Debug Interceptor "> 

<property name="l oggerName"> 

<val ue>tudu. interceptor .debug</val ue> 
</property> 
</bean> 

<bean name="proxyCreator" 
class=" org. springf ramework.aop. framework 

.autoproxy . BeanNameAutoProxyCreator"> 

<property name="beanNames" value="/*"/> 
<property name="interceptorNames"> 
<list> 

<val ue>debugInterceptor</val ue> 
</list> 
</property> 
</bean> 

Concemant le Bean debuglnterceptor, il s'agit de la configuration classique d'un inter- 
cepteur Spring. Le "proxyCreator" est configure pour correspondre au nom "/*", ce qui 
permet d'intercepter 1' ensemble des appels aux actions Struts. 

Cette configuration permet d'obtenir des messages de log particulierement interessants 
pour deboguer une application, comme ici : 



DEBUG tudu . interceptor . debug — Exiting invocation: method 'execute', 
arguments [ActionConfig [path=/ secure/ admin/ administration , name=adminis- 
trationForm, parameter=method, scope=request , type=org. springf rame- 
work . web .struts. DelegatingActionProxy, 

DynaActionForm[dynaClass=administrationForm, smtpHost=smtp . test . com, smtpFr 
om=email@test . com, smtpPassword=password, smtpPort=25 , smtpUser=user] , 
net . sf. acegisecurity . wrapper . ContextHolderAwareRequestWrapperQ 67 631 6, 
org. apache. catalina. connector. ResponseFacade@9a6c56] ; target is of class 
[tudu . web . AdministrationAction ] ; count=4 



Nous retrouvons dans ce message de log l'URL de Taction appelee, ainsi que l'ensemble 
des parametres envoyes, la classe executee et le nombre d'appels a cette URL. 

Ces messages apparaissant en mode debug, il faut, pour les observer, configurer le fichier 
log4j. properties (dans le repertoire JavaSource) de la maniere suivante : 

log4j .logger. tudu. interceptor. debug=DEBUG 

Des intercepteurs peuvent etre ajoutes ou enleves tres facilement. lis servent generalement a 
monitorer l'application. 
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Points forts et points faibles de la solution 

Cette solution permet de combiner les forces de Struts et de Spring : 

• Elle est la plus rapide et la moins couteuse a mettre en oeuvre, car tout developpeur 
maitrisant Struts est presque immediatement operationnel. 

• Du fait de l'injection de dependances et des intercepteurs, l'utilisation de Struts est 
considerablement amelioree par Spring. 

Cependant, elle ne resout pas tous les problemes lies a Struts : 

• Une grande partie des problemes provenant de Struts restent presents, notamment 
l'utilisation de classes et non d'interfaces, la dependance directe a l'API des servlets, 
etc. 

• La configuration necessaire est complexe et necessite une bonne connaissance du 
fichier struts-config.xml et de la configuration de Spring. 

• Les objets ainsi crees sont de mauvaise qualite du point de vue de Spring. lis dependent 
a la fois de l'API servlet et de l'API Struts, les rendant difficiles a tester. 



Conclusion 

Apres une rapide presentation de Struts, ce chapitre a detaille les nombreux problemes 
lies a ce framework populaire mais vieillissant. 

Lintegration de Spring et de Struts permet de beneficier des avantages de chacune de ces 
deux technologies, notamment la vaste communaute d'utilisateurs de Struts et l'injection 
de dependances et la POA proposees par Spring. La combinaison de ces deux techno- 
logies permet de realiser une couche MVC de bonne qualite, sans necessiter la maitrise 
des nouveaux et complexes frameworks MVC a la mode. 

Nous avons etudie les trois methodes classiques d'integration de Spring et de Struts, en 
constatant que la methode de delegation d' action etait generalement la plus interessante. 
Au prix d'une configuration un peu lourde, il est possible d'avoir des objets qui soient a 
la fois des actions Struts et des Beans Spring, beneficiant de la sorte des deux techno- 
logies. 

Ce choix reste un compromis puisqu'il ne resout pas tous les problemes lies a Struts et ne 
permet pas de creer des Beans Spring de bonne qualite, ces derniers dependant des API 
servlet et Struts et restant difficilement testables unitairement. II permet neanmoins de 
combiner intelligemment les forces de ces deux frameworks et d'obtenir un resultat 
rapide sans prendre trop de risques. 

II s'agit done d'un bon compromis pour les equipes possedant deja des competences 
Struts et ne desirant pas passer a un autre framework MVC dans l'immediat. 
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La mise en pratique du pattern MVC (Model View Controller) offre une meilleure struc- 
turation du tiers presentation des applications J2EE en dissociant les preoccupations de 
declenchement des traitements de la construction de la presentation proprement dite. Les 
principaux frameworks MVC implementent le type 2 de ce pattern, qui consiste a instau- 
rer un point d'entree unique ayant pour mission d'aiguiller les requetes vers la bonne 
entite de traitement. 

Malgre des applications structurees et une large utilisation, certains frameworks MVC, 
tels que Struts, nuisent a la flexibilite des applications. En effet, ce dernier contraint le 
developpeur a se lier fortement a ses API et ne favorise pas la mise en place de techno- 
logies de presentation differentes. De plus, il ne fournit pas de solution d' integration a 
une architecture en couches complete. 

Le framework Spring offre une implementation innovante du pattern MVC par le biais 
d'un module nomme Spring MVC, qui profite des avantages de 1'injection de dependances 
(voir chapitres 2 et 3). 

Le present chapitre passe en revue les fonctionnalites et apports de ce module, qui met 
en ceuvre les principes generaux du framework Spring, lesquels consistent a simplifier 
les developpements d' applications J2EE tout en favorisant leur structuration et leur 
flexibilite. 
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Implementation du pattern MVC de type 2 dans Spring 

Cette section decrit brievement 1' implementation du pattern MVC de type 2 dans le 
framework Spring. 

Actuellement, le framework MVC le plus utilise est incontestablement Struts, mais ce 
dernier connait des limitations qui freinent son utilisation et incitent de plus en plus 
d'architectes et de developpeurs a trouver des solutions de rechange. Un sondage non 
officiel publie sur le blog de Matt Raible concernant la popularite des frameworks MVC 
confirme cette tendance et place Spring MVC en premiere place devant Struts. 

Nous ne reviendrons pas sur les concepts de base du pattern MVC, abordes au chapitre 6, 
et nous concentrerons sur les principes de fonctionnement et constituants de Spring 
MVC, 1' implementation du pattern MVC de type 2 par Spring. 



Principes et composants de Spring MVC 

Le framework Spring fournit des integrations avec les principaux frameworks MVC ainsi 
que sa propre implementation. Forts de leur experience dans le developpement d'applica- 
tions J2EE, ses concepteurs considerent que 1' injection de dependances offre un apport 
de taille pour concevoir et structurer des applications fondees sur le pattern MVC. 

Precisons que Spring MVC ne constitue qu'une partie du support relatif aux applications 
Web. Le framework Spring offre d'autres fonctionnalites permettant notamment le char- 
gement des contextes d'application de maniere transparente ainsi que des integrations 
avec d'autres frameworks MVC, tels Struts, JSF, Web Work ou Tapestry. 

Parmi les principes fondateurs de Spring MVC, remarquons notamment les suivants : 

• Utilisation du conteneur leger afin de configurer les differentes entites du pattern MVC 
et de beneficier de toutes les fonctionnalites du framework Spring, notamment au 
niveau de la resolution des dependances. 

• Favorisation de la flexibilite et du decouplage des differentes entites mises en oeuvre 
grace a la programmation par interface. 

• Utilisation d'une hierarchie de contextes d'application afin de realiser une separation 
logique des differents composants de 1' application. Par exemple, les composants des 
services metier et des couches inferieures n'ont pas acces a ceux du MVC. 

Les composants du MVC ont pour leur part les principales caracteristiques suivantes : 

• Modelisation des controleurs sous forme d' interface et non de classes concretes. Ce 
choix de conception permet d'implementer facilement de nouveaux types de contro- 
leurs tout en beneficiant des avantages de l'heritage. Ce choix favorise la mise en 
oeuvre des tests unitaires des controleurs. 

• Gestion des formulaires a l'aide d'un controleur specifique permettant non seulement 
de charger et d'afficher les donnees du formulaire mais egalement de gerer leur 



Spring MVC 

Chapitre 7 



soumission. Ces donnees sont utilisees pour remplir directement un Bean sans lien 
avec Spring MVC, qui peut etre valide si necessaire. 

• Abstraction de 1' implementation des vues par rapport aux controleurs permettant de 
changer de technologie de presentation sans impacter le controleur. 

• Abstraction par rapport aux API servlet. Grace aux differentes implementations des 
controleurs, les implementations des controleurs ne se lient pas systematiquement a 
ces API, lesquelles sont en outre masquees lors de 1' implementation du passage du 
controleur a la vue. 

• Possibility d'implementer et de configurer des intercepteurs directement au niveau du 
MVC sans passer par la POA. 

Pour mettre en oeuvre ces principes et composants, Spring MVC s'appuie sur les entites 
illustrees a la figure 7.1. 
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Figure 7.1 

Entites de traitement des requetes de Spring MVC 



Les principaux composants de Spring MVC peuvent etre rassembles en trois groupes, 
selon leur fonction : 

• Gestion du controleur facade et des contextes d 'application. Permet de specifier les 
fichiers des differents contextes ainsi que leurs chargements. Le controleur facade doit 
etre configure de facon a specifier l'acces a I'application. 

• Gestion des controleurs. Consiste a configurer la strategie d'acces aux controleurs, 
ainsi que leurs differentes classes d' implementation et leurs proprietes. 

• Gestion des vues. Consiste a configurer la ou les strategies de resolution des vues ainsi 
que les frameworks ou technologies de vue mis en ceuvre. 
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Initialisation du framework Spring MVC 

L' initialisation du framework Spring MVC s'effectue en deux parties, essentiellement au 
sein du fichier web.xml puisqu'elles utilisent des mecanismes de la specification J2EE 
servlet. 



Gestion des contextes 

Le framework Spring permet de charger automatiquement les contextes d' application en 
utilisant les mecanismes des conteneurs de servlets. 

Dans le cadre d' applications J2EE, une hierarchie de contextes est mise en ceuvre arm de 
regrouper et d'isoler de maniere logique les differents composants. De la sorte, un 
composant d'une couche ne peut acceder a celui d'une couche superieure. 

Contexte 

Rappelons qu'un contexte correspond au conteneur leger en lui-meme, dont la fonction est de gerer des 
Beans (voir chapitres 2 et 3). Le framework offre egalement un mecanisme permettant de definir une 
hierarchie de contextes afin de realiser une separation logique entre des groupes de Beans. Dans le cas 
du MVC, il s'agit d'empecher I'utilisation de composants du MVC par des composants service metier ou 
d'acces aux donnees. 

Le framework Spring offre une hierarchie pour les trois contextes suivants : 

• Contexte racine. Ce contexte tres utile pour partager des objets d'une meme biblio- 
theque entre plusieurs modules d'une meme application Java/J2EE peut etre partage au 
niveau du chargeur de classes. 

• Contexte de l'application Web. Stocke dans le ServletContext, ce contexte doit 
contenir la logique metier ainsi que celle de l'acces aux donnees. 

• Contexte du framework MVC. Gere par le controleur facade du framework, ce 
contexte doit contenir tous les composants relatifs au framework MVC utilise. 

La figure 7.2 illustre cette hierarchie ainsi que la portee des differents contextes. 
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La mise en oeuvre du contexte de 1' application Web est obligatoire, tandis que celle du 
contexte racine est optionnelle et n'est done pas detaillee ici. Si ce dernier est omis, 
Spring positionne de maniere transparente celui de 1' application Web en tant que 
contexte racine. 

L' initialisation du contexte de l'application Web, que nous detaillons dans ce chapitre, est 
independante du framework MVC choisi et utilise les mecanismes du conteneur de 
servlets. Sa configuration est identique dans le cadre du support de Struts aborde au 
chapitre precedent. 

Chargement du contexte de l'application Web 

Le framework Spring fournit une implementation de la classe ServletContextListener de 
la specification servlet permettant de configurer et d'initialiser ce contexte au demarrage 
et de le finaliser a 1' arret de l'application Web. 

Cette fonctionnalite est utilisable avec un conteneur de servlets supportant au moins la 
version 2.3 de la specification. Cet ecouteur se parametre dans les fichiers de configura- 
tion XML du contexte en ajoutant les lignes suivantes dans le fichier web.xml de l'appli- 
cation : 

<context-param> 

<param-naine>contextConf igl_ocation</param-name> 

<param-val ue>/WEB-INF/appl icationContext*.xml </param-val ue> 

</context-param> 

<1 i stener> 

<1 i stener-cl ass> 

org. springf ramewor k. web. context. Context Loader Li stener 

</l i stener-cl ass> 
</l i stener> 

Au cas oil le serveur d' applications utilise supporte une ancienne version (anterieure a la 
2.2 incluse), le framework Spring fournit une servlet afin de realiser les memes traite- 
ments de configuration et d' initialisation. Les lignes suivantes doivent en ce cas etre 
ajoutees dans le fichier web.xml a la place des precedentes : 

<context-param> 

<param-name>contextConfigLocation</param-name> 

<param-val ue>/WEB-INF/appl icationContext*.xml </param-val ue> 

</context-param> 

<servlet> 
(...) 

<servlet-cl ass> 

org. springf ramewor k. web. context. Con text LoaderServl et 
</servl et-cl ass> 
</servlet> 
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Chargement du contexte de Spring MVC 

La configuration tout comme le chargement de ce contexte sont lies a ceux de la servlet 
du controleur facade de Spring MVC. Precisons que, par defaut, cette derniere initialise 
un contexte d' application fonde sur un fichier <nom-servlet>-servlet.xml, lequel utilise 
le nom de la servlet precedente pour <nom-servlet>, ce fichier se situant par defaut dans le 
repertoire WEB-INF et la valeur de <nom-servlet> etant specifiee grace a la balise 
serv let-name. Dans 1' etude de cas, la servlet de Spring MVC s'appelle action, et le fichier 
action-servlet.xml contient les differents composants utilises par ce framework, comme 
les controleurs, les vues et les entites de resolution des requetes et des vues. 

Nous pouvons personnaliser le nom de ce fichier a l'aide du parametre d'initialisation 
contextConfigLocation de la servlet. Le code suivant montre la facon de specifier un 
fichier mvc-context.xml pour le contexte de Spring MVC : 

<web-app> 
(...) 
<servlet> 

<servl et-name>exampl e</servlet-name> 
<servlet-class> 

org.springframework.web.servlet.DispatcherServlet 
</servl et-cl ass> 

<load-on-startup>K/load-on-startup> 
<init-param> 

<param-name>contextConf igl_ocation</param-naine> 
<param-val ue>/WEB-INF/mvc-context .xml </param-val ue> 
</init-param> 
</servlet> 
</web-app> 



Initialisation du controleur fagade 

Le fait que le framework Spring MVC implemente le pattern MVC de type 2 signifie 
qu'il met en oeuvre un controleur facade qui dirige les traitements vers des classes designees 
par le terme Controller dans Spring MVC. 



Le controleur facade 

Cette entite correspond a I'unique point d'acces de I'application Web. Son role est de rediriger les traite- 
ments vers le bon controleur en se fondant sur I'adresse d'acces pour traiter la requete. Dans le cas 
d'applications Web, ce controleur est implemente par le biais d'une servlet, qui est generalement fournie 
par le framework MVC utilise (voir le chapitre 6, dedie a Struts). 



Ce controleur fagade est implemente par le biais de la servlet org . spri ngf ramework. web . serv- 
let.DispatchServlet, cette derniere devant etre configured dans le fichier WEB-INF/ 
web.xml. 
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Le mappage de la ressource est defini au niveau du conteneur de servlets dans le fichier 
WEB-INF/web.xml (Spring ne pose aucune restriction a ce niveau) : 

<web-app> 
(...) 
<servlet> 

<servlet-name>exampl e</servl et-name> 
<servlet-class> 

org.springf ramework.web.servlet.DispatcherServlet 
</servl et-cl ass> 

<load-on-startup>K/l oad-on-startup> 
</servl et> 
<servlet-mapping> 

<servl et-name>exampl e</servl et-name> 

<url -pattern>*.html</url -pattern> 
</servlet-mapping> 
</web-app> 

Notons que Spring MVC n'impose pas le mapping pour la servlet principale. Dans notre 
cas, nous avons choisi arbitrairement *.html. 

En resume 

Cette section a detaille les mecanismes de chargement des contextes et de configuration 
du controleur facade du framework Spring MVC puis a montre comment configurer et 
implementer les differentes entites de ce framework. 

Nous allons maintenant detailler la facon dont Spring MVC gere les requetes et les vues. 

Traitement des requetes 

La mise en place de la partie controleur du MVC commence par la configuration de la 
correspondance des URI avec des classes de traitement. 

Elle se poursuit eventuellement par des interceptions sur des requetes puis par 1' imple- 
mentation de ces controleurs de traitement. 

Selection du controleur 

Comme pour tout framework implementant le pattern MVC de type 2, un mecanisme de 
correspondance entre la classe de traitement appropriee et l'URI de la requete est integre. 
Le framework configure la strategie choisie grace au fichier de configuration du contexte 
de Spring MVC. 

Afin de configurer ce mecanisme, il est indispensable de bien comprendre la structure de 
l'URL d'une requete, qui apparait toujours sous la forme suivante dans les applications 
J2EE : 

http://<machine>:<port>/<al ias-webapp>/<al ias-ressource-web> 
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L'URI correspond a la fin de l'URL : 

/<al ias-webapp>/<al ias-ressource-web> 

L' alias de l'application Web, <al i as-webapp>, est configure au niveau du serveur d'appli- 
cations, contrairement a celui de la ressource Web, <al ias-ressource-web>, qui se realise 
au sein de l'application. 

Dans un premier temps, l'acces a la servlet Di spatchServl et de Spring MVC est parame- 
tre dans le fichier WEB-INF/web.xml afin de prendre en compte un ensemble d'URI 
avec des mappages de la forme *, /quelquechose/* ou *. quelquechose. Nous detaillons la 
configuration de la premiere partie a la section « Initialisation du controleur facade », 
plus loin dans ce chapitre. 

L'etape suivante consiste a configurer Spring MVC afin qu'il selectionne l'entite traitant 
l'URL Spring MVC dispose a cet effet de l'interface HandlerMapping du package 
org. springf ramework. web. servlet, laquelle possede differentes implementations suivant le 
mecanisme de mappage souhaite. Cette interface est decrite ci-dessous (les implementations 
sont localisees dans le package org. springf ramework. web. servlet. handler) : 

public interface HandlerMapping { 
Handl erExecutionChain getHandl er( 

HttpServl etRequest request) throws Exception; 

} 

Passons en revue les diverses implementations de cette interface ainsi que leurs configu- 
rations et fonctionnements. 

Tout d'abord, 1' implementation BeanNameUrl HandlerMapping permet d'utiliser le nom du 
Bean comme correspondance afin de realiser un mappage simple et efficace. 

Dans ce cas, l'attribut name identifie le Bean en lieu et place de l'attribut id : 

<beans> 

<bean id="handlerMapping" class="org.springframework.web 

. servl et. handl er. BeanNameUrl Handl erMapping"/> 

<bean name="/wel come. act ion" cl ass="tudu.web.Wel comeControl 1 er"/> 
<beans> 

La configuration precedente dirige les traitements vers le controleur ayant le nom 
wel come . acti on pour les URL de la forme suivante : 

http://<machine>:<port>/<al ias-webapp>/welcome.action 

Spring MVC fournit egalement 1' implementation SimpleUrl HandlerMapping, plus flexible, 
qui permet d'associer des Beans a des requetes sans utiliser leur attribut name. II definit le 
controleur correspondant a un ou plusieurs URI par 1' intermediate d'une expression 
reguliere specifiee dans la propriete mapping. Le code suivant montre l'adaptation de la 
configuration precedente a cette implementation : 

<beans> 

<bean id="handlerMapping" class="org.springframework.web 

.servlet. handler. SimpleUrl Handl erMapping"> 
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<property name="mappings"> 
<props> 

<prop key="/wel come.action">wel comeControl 1 er</prop> 
</props> 
</property> 
</bean> 

<bean id="wel comeControl 1 er" cl ass="tudu.web.Wel comeControl 1 er"/> 
<beans> 

Par 1' intermediate de cette strategie, le lien avec les controleurs se realise par nom et non 
par reference. 



Interception des requites 

Spring MVC offre la possibility de realiser des interceptions au niveau du traitement des 
requetes. Ces interceptions utilisent des mecanismes specifiques du framework, qui, sans 
relever des concepts de la POA, permettent d'executer des traitements avant et apres 
l'execution du controleur associe a la requete ainsi qu'a la fin de la construction de la 
vue. 

Un intercepteur de Spring MVC doit implementer l'interface suivante Handl erlnterceptor du 
package org.springframework.web.servlet ou etendre la classe Handl erlnterceptorAdapter 
afin de ne pas avoir a redefinir les methodes non utilisees : 

public interface Handlerlnterceptor { 

boolean preHandle(HttpServletRequest request, 
HttpServl etResponse response, 
Object handler) throws Exception; 

void postHandle(HttpServletRequest request, 
HttpServl etResponse response, 
Object handler, 

ModelAndView modelAndView) throws Exception; 

void afterCompletiontHttpServletRequest request, 
HttpServletResponse response, 
Object handler, 

Exception ex) throws Exception; 

Le code suivant montre une implementation d'un intercepteur de mesure des temps de 
reponse des controleurs fonde sur le framework JAMon : 

public class JAMonlnterceptor extends Handl erlnterceptorAdapter { 

public boolean preHandle(HttpServletRequest request, 
HttpServletResponse response, 
Object handler) throws Exception { 
Monitor monitor = 

Moni tor Factory. start (handl er .getCl ass( ) .get Name ( ) ) ; 
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request. setAttribute( "monitor" .monitor) ; 
return true; 

} 

public void postHandle(HttpServletRequest request, 

HttpServletResponse response. Object handler, 
ModelAndView model AndView) throws Exception { 
Monitor monitor = (Monitor)request.getAttribute("monitor"); 
monitor. stop( ) ; 

request . removeAttribute( "monitor" ) ; 

} 

} 

Dans le cadre de 1' utilisation de la classe Simpl eUrl Handl erMappi ng, l'intercepteur se confi- 
gure grace a la propriete interceptors, comme ci-dessous : 

<beans> 

<bean id="handlerMapping" class="org.springframework 

. web. servlet. handler. Si mpleUrl Handl erMappi ng"> 
<property name="interceptors"> 
<list> 

<ref bean=" jamonInterceptor"/> 
</list> 
</property> 

<property name="mappings"> 
<props> 

<prop key="/welcome.action"> 

wel comeControl 1 er 
</prop> 
(...) 
</props> 
</property> 
</bean> 

<bean id=" jamon Interceptor" cl ass=" samples .J AMon Interceptor "/> 
<beans> 

Un intercepteur arrete la chaine d'execution des traitements si la valeur f al se est retournee 
par la methode preHandl e. 



Les types de contrdleurs 

Spring MVC fournit une interface de base pour les controleurs que le developpeur est 
libre d'implementer directement. II peut egalement utiliser les implementations des 
controleurs fournis par le framework qui adressent des problematiques specifiques en 
mettant souvent en oeuvre un cycle de traitement des requetes. 

Les sections qui suivent detaillent l'interface de base des controleurs ainsi que ses princi- 
pales implementations fournies par Spring MVC. 
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Controleur simple 

L' abstraction de base est l'interface Controller, situee dans le package org.springfra- 
mework.web.mvc, qui definit la methode handl eRequest comme point d'entree : 

public interface Controller { 

ModelAndView handleRequest(HttpServletRequest request, 

HttpServletResponse response) throws Exception; 

} 

Ce controleur de base convient bien pour mettre en ceuvre un traitement specifique sans 
gestion de formulaire. Le code suivant donne un exemple d'utilisation de cette interface 
issu de Tudu Lists : 

public class ShowTodosController implements Controller { 
(...) 

ModelAndView handleRequesttHttpServletRequest request, 

HttpServletResponse response) throws Exception { 
Collection<TodoList> todoLists = new TreeSet<TodoList>( 
userManager.getCurrentUsert ) .getTodoLi sts( ) ) ; 
Map<String,Object> model=new HashMap<String,Object>( ) ; 
model .put( " default List" , 1 istld) ; 
return new ModelAndViewC'todos", model ); 

} 

} 

II se configure comme un Bean dans le contexte de Spring MVC et doit etre reference par 
1' implementation de mappage choisie, comme ci-dessous : 

<beans> 

<bean id="showTodosController" 

cl ass=" tudu. web. ShowTodosControl 1 er"/> 

<bean id="handlerMapping" class="org.springframework 

. web. servlet. handler. Si mpl eLI rl Handl erMapping"> 
<property name="mappings"> 
<props> 

<prop key="/showTodos.action"> 

ShowTodosControl ler 
</prop> 
(...) 
</props> 
</property> 
</bean> 
</beans> 

Controleur a entree multiple 

Spring MVC fournit egalement dans le package org.springframework.web.mvc.multiaction 
1' implementation MultiActionController, qui permet de mettre en ceuvre des controleurs 
avec plusieurs points d'entree. Les methodes de ces controleurs doivent repondre a des 
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criteres stricts de signature et posseder la meme signature que la methode handleRequest 
au nom pres. 



Point d'entree 

Dans le contexte du pattern MVC, un point d'entree correspond a une methode d'un composant qui peut 
etre appele par le conteneur ou le framework qui le gere. Cette methode suit habituellement des conven- 
tions specifiques quant a sa signature. 



L'une ou 1' autre des deux approches suivantes sont envisageables pour mettre en oeuvre 
cette implementation : 

• Etendre la classe MultiActionController, qui contient des lors la logique permettant de 
selectionner la methode du controleur a executer. Les methodes possibles doivent avoir 
une signature normalised au niveau des parametres d'entree et de retour. 

• Definir une classe independante contenant les methodes des points d'entree auxquelles 
la classe MultiActionController delegue les traitements. L' implementation n'a aucune 
adherence avec Spring MVC, mais les signatures des methodes doivent etre normalisees, 
comme precedemment. 

L'exemple suivant illustre 1' adaptation du code du controleur precedent afin de supporter 
plusieurs points d'entree : 

public class ShowTodosControl 1 er extends MultiActionController { 
(...) 

ModelAndView showTodos(HttpServletRequest request, 

HttpServl etResponse response) throws Exception { 
Collection<TodoList> todoLists = new TreeSet<TodoList>( 
userManager .getCurrentUser( ) .getTodoLi sts( ) ) ; 
Map<String,Object> model=new HashMap<String,Object>(); 
model .putt "default Li st" , 1 istld) ; 
return new ModelAndView( "todos" .model ) ; 

} 

} 

Une fois le controleur implements, la strategie d'appel doit etre specifiee afin de faire 
correspondre la requete avec une methode du controleur. Spring MVC fournit differentes 
strategies pour cela, configurables par le biais de la propriete methodNameResolver du 
controleur de type MethodNameResol ver. 

Les approches decrites dans la suite de cette section correspondent a differentes imple- 
mentations de l'interface MethodNameResolver et sont localisees dans le package 
org. springf ramework. web. servlet.mvc.multi action. 

Le code suivant decrit cette interface : 

public interface MethodNameResolver { 

String getHandlerMethodNametHttpServletRequest request); 
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La classe ParameterMethodNameResolver, symbolisant la premiere implementation, utilise 
un parametre de la requete devant etre present dans l'URL de cette derniere ou dans un 
formulaire HTML. Cette approche se configure de la maniere suivante : 

<bean id="paramResol ver" class="org.springframework.web.servlet 

. mvc.multi action. Pa rameterMethodNameResol ver"> 
<property name="paramName"><val ue>method</val ue></property> 
</bean> 

<bean id="showTodosController" 

cl ass="tudu.web.ShowTodosControl 1 er"> 
<property name="methodNameResol ver" ref="paramResol ver"/> 
</bean> 

Seconde implementation et strategie par defaut de la classe MultiActionController, la 
classe Internal PathMethodNameResol ver travaille directement sur l'URI de la requete. Cette 
implementation est la strategie par defaut de Mul ti Acti onControl 1 er, et aucune configuration 
specifique n'est necessaire. 

La classe PropertiesMethodNameResolver est la derniere implementation. Elle utilise une 
propriete de type Properties pour definir la correspondance entre l'URI des requetes et 
un nom de methode du controleur. Elle se configure de la maniere suivante : 

<bean id="paramResol ver" class="org.springframework.web.servlet 

. mvc.multi act ion. PropertiesMethodNameResol ver "> 
<property name="mappings"> 
<props> 

<prop key="/secure/showTodos.action">showTodos</prop> 
</props> 
</property> 
</bean> 

<bean id="showTodosController" 

cl ass="tudu.web.ShowTodosControl 1 er"> 
<property name="methodNameResol ver" ref="paramResol ver"/> 
</bean> 

Controleur de gestion de formulaire 

Spring MVC fournit un support pour l'affichage des donnees des formulaires et leur 
soumission au travers de 1' implementation SimpleFormController. 

Ce type de controleur utilise un objet designe par Spring MVC par le terme Command, qui 
est configure au travers des proprietes commandName et commandCl ass. Cet objet correspond 
au modele du pattern MVC. II est implemente grace a un simple Bean Java, totalement 
independant du framework, ce qui lui permet d'etre utilise par les composants des 
couches inferieures. 
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Voici la configuration du Bean de type Regi sterData pour le controleur Regi sterControl 1 er : 

<bean id=" regi sterControl 1 er" cl as s="tudu. web. Regi sterControl 1 er"> 
<property name="commandName" val ue="register"/> 
<property name="commandCl ass" 

val ue="tudu. web. bean . Regi sterData "/> 

(...) 

</bean> 

La section suivante se penche sur la facon dont 1' implementation SimpleFormController 
gere les formulaires HTML. 

Affichage du formulaire 

L implementation Simpl eFormControl 1 er offre la possibility de charger les differentes enti- 
tes necessaires a rafhchage du formulaire dans la vue. Elle utilise pour cela differentes 
methodes de rappel que le developpeur peut surcharger suivant ses besoins. 

L' affichage du formulaire est realise grace a l'appel du controleur par la methode GET. 
Le cycle d'enchainement des methodes est illustre a la figure 7.3. 



Figure 7.3 
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Spring MVC utilise d'abord la methode formBackingObject dans le but de recuperer une 
instance de l'objet sur laquelle le formulaire va se fonder. Son comportement par defaut cree 
une nouvelle instance a chaque demande d'affichage du formulaire, laquelle peut etre 
surchargee afin de renvoyer une instance initialisee avec des valeurs de la base de donnees. 

Le code suivant, tire de Tudu Lists, donne un exemple de surcharge de la methode form- 
BackingObject : 

public class MylnfoControl 1 er extends SimpleFormController { 
(...) 

protected Object formBackingObject(HttpServletRequest request) 

throws ServletException { 
String login = request. getRemoteUserO; 
User user = userManager.findllser(login) ; 
UserlnfoData data=new UserInfoData( ) ; 
data .set Password (user .get Password ( ) ) ; 
data. setVerify Password ( user. get Password ( ) ) ; 
data .set Fi rstName( user. get Fi rstNamet ) ) ; 
data .set Last Name (user .get Las tNamet ) ) ; 
data .set Emai 1 (user. get Emai 1 ( ) ) ; 
return data; 

} 

(...) 

} 

Les Property Editor personnalises ajoutes grace a la methode initBinder permettent de 
convertir les proprietes du Bean de formulaire en chaines de caracteres affichables dans 
des champs. 

Le code suivant indique la facon d'ajouter un PropertyEditor dans un controleur : 

public class MylnfoControl 1 er extends SimpleFormController { 
(...) 

protected void initBinder(HttpServletRequest request, 

ServletRequestDataBinder binder) throws Exception { 
binder. registerCustomEditor(MyClass.cl ass, 

new MyPropertyEditor( ) ) ; 

} 

(...) 

} 

La methode onBindOnNewForm permet de positionner des valeurs sur le Bean de formulaire 
une fois celui-ci rempli automatiquement avec des donnees passees dans l'URI. 

Pour finir, la methode referenceData offre la possibility d'ajouter au modele des donnees 
necessaires a la construction du formulaire, comme les valeurs d'une liste de selection. 

Le code suivant montre la fagon de surcharger cette methode : 

public class MylnfoControl 1 er extends SimpleFormController { 
(...) 

protected Map referenceData(HttpServletRequest request) 

throws Exception { 
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Map model=new HashMapO; 
model .putC'data", "my data"); 
return model ; 

} 

(...) 

} 

Soumission du formulaire 

L' implementation SimpleFormController permet egalement de traiter les donnees soumi- 
ses par un formulaire grace a differentes methodes de rappel, que le developpeur peut 
surcharger comme precedemment. 

Avec Spring MVC, la soumission d'un formulaire doit etre realisee par l'appel du contro- 
leur avec la methode POST. Le cycle d'enchainement des methodes correspondant est 
illustre a la figure 7.4. 

Figure 7.4 
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Les premieres mefhodes (formBackingObject, initBinder) fonctionnent de la meme 
maniere que precedemment, et la methode onBind comme onBindOnNewForm. Cette derniere 
est particulierement utile afin de positionner une propriete de type complexe en 
s'appuyant sur des donnees annexes. 

Une validation des donnees d'un formulaire peut etre mise en oeuvre si necessaire. Spring 
MVC introduit a cet effet 1' interface Val i da tor, dont le code est le suivant : 

public interface Validator { 

boolean supports(Class clazz); 

void val idate(Object obj , Errors errors); 

} 

La methode supports permet de specifier sur quel Bean de formulaire peut etre appliquee 
l'entite de validation. La methode val i date doit contenir 1' implementation de la validation et 
utiliser l'instance de l'interface Errors associee. 

Le ou les validateurs sont associes au controleur par l'intermediaire de sa propriete val i - 
dator, comme dans le code ci-dessous : 

<bean id="regi sterControl ler" cl ass="tudu.web. Regi sterControl ler"> 
(...) 

<property name="val idator" value="register"/> 
(...) 
</bean> 

<bean id="registerValidator" 

class="tudu.web.val idator.RegisterVal i dator" /> 

Le code suivant de la classe Regi sterVal idator montre que 1' implementation du valida- 
teur permet de specifier des erreurs aussi bien a un niveau global (repere Q) que sur 
chaque propriete du formulaire (repere Q> en s'appuyant sur l'interface Errors : 

public class RegisterVal idator implements Validator { 

public boolean supports(Cl ass clazz) { 

return Regi sterData .cl ass .i sAssignableFrom(cl azz) ; 

} 

public void val idatetObject command. Errors errors) { 

Val i dat i onUt i 1 s. reject I fEmptyOrWhitespacet errors, "login", 

"errors . requi red" , new Object[] {"login"}, "");<-© 

Val idationUtil s . reject I fEmptyOrWhitespacet errors , "password" , 

"errors . requi red" , new Object[] ("password"), "");<-© 

Val idationUtil s . reject I fEmptyOrWhitespacet 
errors, "verifyPassword" , 

"errors . requi red" , new Object[] {"verifyPassword"), "");<-© 
ift !data .getPasswordt ) .equal stdata .getVerifyPasswordt ) ) ) { 
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errors . rejectVal ue( "verify Password" , "errors . requi red" , 
new Object[] {"verifyPassword"} , "");<-@ 

} 

Val idationUti 1 s . reject If EmptyOrWhi tespace( errors , "f i rstName" , 
"errors . requi red" , new Object[] {"firstName"), "");<-© 
Val idationUti 1 s . rej ect If EmptyOrWhi tespacet 
errors, "lastName", 

"errors . requi red" , new Object[] {"lastName"), "");<-© 



if( errors . hasErrors( ) ) { 
errors . re j ect ( "register, info. 1" ) ;<~0 

} 

} 

} 

Pour finir, la methode processFormSubmission permet de traiter les donnees soumises et de 
les reafncher si des erreurs de conversion ou de validation se sont produites. 

En cas de succes, les traitements sont delegues a la methode onSubmit a surcharger, 
comme le montre le code suivant de la classe Mylnf oControl 1 er issue de l'etude de cas : 

public class MylnfoControl 1 er extends SimpleFormController { 
(...) 

protected ModelAndView onSubmit(HttpServletRequest request, 
HttpServletResponse response. Object command, 
BindException errors) throws Exception { 

UserlnfoData data = (UserlnfoData) command; 

String password = data.getPasswordO; 

String firstName = data . getFi rstNamet ) ; 

String lastName = data .getl_astName( ) ; 

String email = data .getEmai 1 ( ) ; 

String login = request. getRemoteUsert ) ; 

User user = userManager.findUser(login) ; 

user. set Password (password) ; 

user .set Fi rstNamet fi rstName) ; 

user. set LastName (lastName) ; 

user.setEmail (email ) ; 

userManager.updateUser(user) ; 

return showForm(request, response, errors) ; 

} 

(...) 

} 

Lors de l'utilisation d'une vue fondee sur JSP/JSTL, la balise <bind> de Spring offre un 
support a l'affichage des donnees du formulaire ainsi des erreurs de validation. Son utili- 
sation est detaillee plus loin dans ce chapitre. 
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Gestion des exceptions 

Par defaut, Spring MVC fait remonter les differentes exceptions levees dans le conteneur de 
servlets. II est cependant possible de modifier ce comportement par 1' intermediate de l'inter- 
face HandlerExceptionResol ver, localisee dans le package org. spri ngf ramework. web. servl et : 

public interface HandlerExceptionResolver { 

ModelAndView resolveException(HttpServletRequest request, 

HttpServl etResponse response, Object handler, Exception ex); 

} 

Le developpeur peut choisir d'utiliser ses propres implementations ou la classe Simple- 
MappingExceptionResolver du package org. spri ngf ramework. web. servlet. handler fournie 
par le framework. Cette derniere permet de configurer les exceptions a traiter ainsi que 
les vues qui leur sont associees. L' exception est alors stockee dans la requete avec la cle 
exception, ce qui la rend disponible pour un eventuel affichage. 

Cette implementation se parametre de la maniere suivante : 

<bean id="exceptionResolver" class="org. spring-framework. web 

.servlet. handler. Si mpleMappingExcepti on Resol ver "> 
<property name= "except ionMappings"> 
<props> 

<prop key=" org. spri ngf ramework. dao. Da taAccess Exceptions 

dataAccessFailure 
</prop> 

<prop key=" org. spri ngf ramework. transaction 

.Trans act ion Exceptions 

dataAccessFailure 
</prop> 
</props> 
</property> 
</bean> 



Spring MVC et la gestion de la vue 

Cette section se penche sur la facon dont sont traitees les vues. 

Nous commencons par detailler la maniere dont sont mis en correspondance les identi- 
fiants de ces vues et leurs implementations. Nous abordons ensuite les differents supports 
des technologies de presentation. 

Selection de la vue et remplissage du modele 

Spring MVC abstrait completement la vue du controleur, masquant ainsi sa technologie 
et sa mise en oeuvre. Au niveau du controleur, le developpeur a la responsabilite de 
remplir le modele avec les instances utilisees dans la vue et de specifier son identifiant. 

Spring MVC fournit pour cela la classe ModelAndView dans le package org. spri ngf ra- 
mework. web. servlet, dont une instance est renvoyee par la methode handleRequest des 
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controleurs. Les donnees vehiculees par cette classe sont utilisees afin de selectionner la 
vue, la classe lui fournissant les donnees du modele. De ce fait, le developpeur ne mani- 
pule plus 1' API servlet pour remplir le modele et passer la main aux traitements de la vue. 

Les donnees du modele sont stockees sous forme de table de hachage. Le code suivant 
donne un exemple de mise en oeuvre de ce mecanisme, dans lequel 1'identifiant todos 
correspond a un nom symbolique de vue configure dans Spring MVC : 

Collection<TodoList> todoLists = new TreeSet<Todol_ist>( 

userManager .getCurrentllser( ) .getTodoLi sts( ) ) ; 
Map<String,Object> model=new HashMap<String,Object>(); 
model .put( "default Li st" , 1 1st Id) ; 
ModelAndView model=new Model AndViewt "todos" .model ) ; 

Configuration de la vue 

La selection des vues dans Spring MVC est realisee par le biais d'une implementation de 
l'interface ViewResol ver dans le package org. springf ramework. web. servlet, comme le montre 
le code suivant : 

public interface ViewResol ver { 

View resolveViewName(String viewName, Locale locale); 

} 

Les sections qui suivent detaillent les differentes implementations de cette interface. 
La figure 7.5 illustre la hierarchie de ces classes et interfaces. 



Figure 7.5 
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AbstractCachingViewResolver 



UrIBasedViewResolver 



ResourceBundle ViewResolver 



XmlViewResolver 



InternalResource ViewResolver 



AbstractTemplate ViewResolver 



Spring MVC 

Chapitre 7 



ResourceBundle ViewResolver 

La premiere implementation, ResourceBundleViewResolver, correspond a une configuration au 
cas par cas des vues utilisees. Cette approche est particulierement interessante pour une utili- 
sation de vues fondees sur differentes technologies de presentation. Sa configuration 
s'effectue par le biais d'un fichier de proprietes contenant le parametrage des differentes vues. 

Cette classe peut toutefois devenir vite contraignante si la majeure partie des vues utilise 
la meme technologie de presentation. Les applications qui utilisent JSP/JSTL et des vues 
PDF ou Excel pour afficher des etats sont un exemple de cette contrainte. Spring MVC 
offre cependant une solution fondee sur le chainage de ViewResolver pour optimiser la 
resolution de ce probleme. 

Le code suivant montre de quelle maniere configurer cette implementation avec Spring 
MVC : 

<bean id="viewResolver" class="org. spring-framework 

.web.servlet.view.ResourceBundleViewResol ver"> 
<property name="basename" value="views"/> 
</bean> 

La propriete basename permet de specifier le fichier de proprietes utilise, qui, dans l'exem- 
ple suivant, apournom views .properties : 

regis ter_ok. ( cl ass ) =org. spr ingf ramework. web. servlet. view. Redi rectView 
register_ok.url=wel come. action 

recover_password_ok. (cl ass) 

=org. spr ingf ramework. web. servlet. view. Redi rectView 
recover_password_ok. url =wel come. act i on 

todo_l i sts_report . (cl ass)=tudu.web.ShowTodoLi stsPdfView 

rssFeed. (cl ass )=tudu.web. RssFeedView 

rss Feed, sty 1 esheetl_ocation=/WEB-INF/xsl /rss .xsl 

Ce fichier possede les configurations des vues de redirection ainsi que des vues fondees 
sur la technologie XSLT et le framework iText. 

Xml ViewResolver 

Les vues sont definies par 1' intermediate de cette implementation au cas par cas, comme 
precedemment, mais dans un sous-contexte de Spring. L utilisation de toutes les facilites 
et mecanismes du framework est done envisageable, de meme que l'injection de depen- 
dances sur la classe d' implementation des vues. 

La configuration de cette implementation se realise de la maniere suivante en utilisant par 
defaut le fichier WEB-INF/views.xml, tout en n'ecartant pas la possibilite d'en specifier 
un autre par le biais de la propriete location : 

<bean id="viewResolver" 

cl as s=" org. spr ingf ramework. web. servlet. view. Xml ViewResol ver"> 
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<property name="order" value="2" /> 

<property name="localtion" val ue="/WEB-INF/views.xml " /> 
</bean> 

Le code suivant donne un exemple de fichier views.xml tire de Tudu Lists : 

<beans> 

<bean id="todo_lists_report" 

cl ass="tudu.web.ShowTodol_istsPdfView"/> 

<bean id="backup" class="tudu.web.BackupTodol_istView"> 
<property name="styl esheet Location" 

val ue=" /WEB- INF/xsl /backup. xsl"/> 
<property name="todol_istsManager" ref="todol_istsManager"/> 
</bean> 
</beans> 

InternalResource ViewResolver 

L' implementation Internal ResourceViewResolver utilise les URI dans le but de resoudre 
les vues fondees, par exemple, sur les technologies JSP/JSTL. Ce mecanisme construit 
l'URI a partir de l'identifiant de la vue puis dirige les traitements vers d'autres ressources 
gerees par le conteneur de servlets, telles que des servlets ou des JSP, comme dans 
1' exemple ci-dessous : 

<bean id="jspViewResolver" class="org. spring-framework. web 

.servlet.view. Internal ResourceViewResol ver"> 
<property name="viewClass" 

val ue="org.springframework. web. servlet.view. Jstl View"/> 
<property name="pref ix" val ue="/WEB-INF/jsp/"/> 
<property name="suff ix" val ue=" . jsp"/> 
</bean> 

Cette implementation generale s' applique a toutes les vues, exceptees celles qui sont 
resolues precedemment par une autre implementation dans une chaine de ViewResol ver. 

Chamage d' implementations de ViewResolver 

Spring MVC offre la possibilite de chainer les entites de resolution des vues. Le 
framework parcourt en ce cas la chaine jusqu'a la decouverte du Vi ewResol ver approprie. 

Certaines de ces entites s'appliquant a toutes les vues, une strategie par defaut de resolu- 
tion des vues peut etre definie. Les implementations fondees sur UrlBasedViewResolver, 
telles que Internal ResourceViewResolver, fonctionnent sur ce principe. 

L' utilisation des vues fondees sur JSP/JSTL peut etre specifiee. D'autres vues, comme 
des redirections ou des vues generant des flux PDF ou Excel, sont definies ponctuellement 
dans un fichier. 
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La figure 7.6 illustre un exemple de chainage d' implementations de l'interface de View- 
Resol ver tire de Tudu Lists. 



Figure 7.6 

Chainage de 
ViewResolver 
dans Tudu Lists 



Chainage de ViewResolver 



Xml ViewResolver 



Traitements des vues specifiees 
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Internal ResourceViewResol ver 



Traitements par defaut des vues en 
utilisant les technologies JSP /JSTL 



View 



Traitements de la vue en utilisant la 
technologie specifiee dans la 
configuration du resolveur 



JstlView 



Traitements de la vue en utilisant les 
technologies JSP/JSTL 



Sans cette fonctionnalite, la configuration de toutes les vues au cas par cas dans un fichier 
serait necessaire, meme pour celles ne necessitant pas de parametrage specifique. 

Lexemple suivant decrit la configuration du chainage de Vi ewResol ver : 

<bean id="jspViewResolver" class="org.springframework.web 

. servl et. view. Internal ResourceViewResol ver"> 
<property name="viewCl ass" 

va 1 ue=" org. spr i ngf ramework. web. servl et. view. JstlView" /> 
<property name="pref ix" val ue="/WEB-INF/jsp/"/> 
<property name="suf f ix" valuer". jsp"/> 
</bean> 

<bean id="viewResolver" 

cl ass= "o rg. spr i ngf ramework. web. servl et. view. Xml ViewResolver "> 

<property name="order" value="l"/> 

<property name="location" value="/WEB-INF/views.xml "/> 
</bean> 

La propriete order permet de specifier la position du ViewResolver dans la chaine. Cet 
exemple met en evidence que la classe Internal ResourceViewResol ver ne possede pas cette 
propriete, ce ViewResol ver ne pouvant etre utilise qu'en fin de chaine. 
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Les technologies de presentation 

Spring MVC offre plusieurs fonctionnalites qui simplifient enormement la mise en 
ceuvre des differentes technologies et frameworks de presentation. 

Dans Spring MVC, une vue correspond a une implementation de l'interface View du 
package org.springframework.web.servlet telle que decrite dans le code suivant : 



public interface View { 
void rendertMap model , 



} 



HttpServl etRequest request, 
HttpServletResponse response); 



Cette interface possede plusieurs implementations, localisees dans le package org. spring- 
framework, web. servlet. view ou dans un de ses sous-packages. 

La figure 7.7 illustre la hierarchie de ses classes et interfaces. 
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Figure 7.7 

Hierarchie des implementations de l'interface View 
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Vue de redirection 

Spring MVC definit un type de vue particulier afin de rediriger les traitements vers un 
URI ou une URL par l'intermediaire de la classe Redi rectView. Elle se configure avec 
1' implementation ResourceBundleViewResolver ou XmlViewResolver en imposant de definir 
la propriete url . 

Le code suivant donne un exemple de sa mise en oeuvre dans Tudu Lists : 

register_ok. (class) 

=org.springf ramework. web. servlet. view. Redi rectView 
register_ok. url =wel come. action 

La propriete url permet de specifier l'adresse de redirection correspondante, laquelle est 
dans notre cas relative au contexte de 1' application. 

La figure 7.8 illustre l'enchainement des traitements afin d'utiliser une vue de type Redi - 
rectView. 



DispatchServlet 




Redirect View 






Methode render 




► 


Appelle la methode render pour la 
vue determinee par un ViewResolver. 




Appelle la methode sendRedirect sur 
la requete en utilisant une propriete 
url. 



Figure 7.8 

Enchainement des traitements pour la vue 



Cette vue peut etre configuree plus rapidement et directement dans la configuration des 
controleurs grace au prefixe redi rect : 

<bean id="restoreTodol_i stControl ler" 

cl ass=" tudu. web. RestoreTodoLi stControl 1 er"> 
<property name="todoLi stsManager" ref="todoLi stsManager" /> 
<property name="formView" val ue="restore"/> 
<property name="successView" 

val ue=" redi rect :showTodos .act ion "/> 
<property name="commandName" val ue="restore"/> 
<property name="commandCl ass" 

val ue=" tudu. web. bean. RestoreData"/> 

</bean> 
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Vue fondee sur JSP/JSTL 

Spring MVC fournit une vue fondee sur JSP/JSTL, dirigeant les traitements de la requete 
vers une page JSP dont l'URI est construit a partir de l'identifiant de la vue. 

La figure 7.9 illustre l'enchainement des traitements afin d'utiliser une vue de type Jstl View. 



Internal Resou rceView 

A 



DispatchServlet 




JstlView 


Appelle la methode render pour la 
vue determinee par un ViewResolver. 


Methode render 

Appelle la methode forward sur une 
instance de RequestDispatcher. 


► 



Figure 7.9 

Enchainement des traitements pour la vue 

Le developpeur prend uniquement en charge le developpement de la page JSP, tandis que 
Spring MVC a la responsabilite de mettre a disposition dans la requete tout le contenu du 
modele ainsi qu'eventuellement des informations concernant le formulaire. 

Lors de la mise en ceuvre d'un controleur fonde sur 1' implementation Simpl eFormControl - 
1 er, Spring MVC stocke dans la requete les deux instances suivantes, qui sont utilisables 
dans la page JSP : 

• <commandName>. Cette cle correspond au Bean contenant les donnees initiales du formu- 
laire, une instance de cet element etant recuperee grace a la methode formBackingObject 
du controleur. 

• org. springf ramework. validation. BindException. <commandName>. Cette cle renvoie aux 
eventuelles erreurs de chargement ou de validation du Bean de formulaire. Cet element 
est initialise avec les donnees envoyees lors de la soumission du formulaire. 

La valeur de <commandName> est definie dans la configuration du controleur a l'aide de la 
propriete commandName. 

Spring MVC fournit une balise bind permettant d'initialiser les champs du formulaire et 
d'afficher les eventuelles erreurs survenues. Le code suivant montre 1' utilisation de cette 
balise dans la page JSP WEB-INF/jsp/user_info.jsp de 1' etude de cas : 



(...) 

<tr class="odd"> 
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<td> 

<fmt: message key=" user. info. first. name "/> 
</td> 
<td> 

<spring:bind path="useri nfo.fi rstName"><-0 

<input type="text" name="fi rstName" 

val ue="<c:out val ue="${status. value}"/>"<-0 

size="15" maxl ength="60"/> 
 <font color="red"> 

<c:out val ue="${status.errorMessage}"/X/font><-© 
</spring:bind><-0 

</td> 
</tr> 
(...) 

La balise bind permet de definir un contexte quant au code imbrique par 1' intermediate 
de la variable status donnant acces aux informations de l'entite. Dans notre exemple, sa 
portee est delimitee par les reperes Q et © 

L'entite cible definie dans l'attribut path de la balise peut correspondre aussi bien au 
Bean de donnees lui-meme qu'a une de ses proprietes. La balise bind porte sur la 
propriete fi rstName du Bean de formulaire ayant pour nom userinfo. 

Le contexte permet de recuperer la valeur et un message d'erreur associe eventuel. La 
valeur n'est renseignee que si la balise bind porte sur un champ. 

Les balises et les expressions JSTL peuvent etre utilisees comme dans 1' exemple prece- 
dent. Spring MVC met egalement a disposition les donnees presentes dans le modele. 
Pour une entree ayant pour cle maVari abl e dans le modele, la JSP recupere la valeur de sa 
propriete ma Propriete correspondante de la maniere suivante : 

<c :out value="${maVariable.maPropriete}"/> 

Afin d'utiliser les taglibs JSTL et de Spring, des importations doivent etre placees dans 
les pages JSP, comme dans le code suivant, tire de la page WEB-INF/jspf7header.jsp : 

<%@ taglib prefix="c" uri="http://java. sun.com/jstl/core_rt" %> 
<%@ taglib pref ix="fmt" uri="http://java. sun.com/jstl/fmt_rt" %> 
<%@ taglib prefix="spring" 

uri=" http://www.spri ngframework.org/tags" %> 

Autres vues 

Spring MVC apporte egalement des supports pour toutes sortes de vues qui ne sont pas 
necessairement fondees sur des forwards ou des redirections de requetes. 

Le framework offre ainsi des classes abstraites de base pour les differentes technologies 
suivantes : 

• generation de documents (PDF, Excel, etc.) ; 

• generation de rapports avec Jasper Reports ; 
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• generation de la presentation fondee sur des templates (Velocity, FreeMaker) ; 

• generation de la presentation fondee sur les technologies XML. 

Concernant les vues generant des documents et celles fondees sur les technologies XML, 
le framework Spring MVC instancie les ressources representant le document par le biais 
de methodes generiques. II delegue ensuite les traitements a une methode de la vue afin 
de construire le document ou de convertir le modele dans une technologie donnee. Le 
framework reprend ensuite en main ces traitements afin d'executer eventuellement une 
transformation puis d'ecrire le resultat sur le flux de sortie. 

La figure 7.10 illustre l'enchainement des traitements d'une vue generant un document 
avec le support PDF de Spring MVC. 
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Figure 7.10 

Enchainement des traitements de la vue 



Dans l'exemple decrit a la figure 7.10, la classe MyView etend la classe abstraite 
AbstractPdfView du package org. springf ramework. web. servlet. view afin d'implementer la 
methode abstraite buildPdfDocument. C'est pourquoi la classe MyView ne contient plus que 
les traitements specifiques a 1' application pour la construction du document, son instan- 
tiation et son renvoi au client etant encapsules dans la classe AbstractPdfView. 
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En resume 

Dans cette section, nous avons approfondi les principes de gestion de la presentation 
dans Spring MVC. 

Ce framework met en ceuvre des mecanismes de mise en relation d'un identifiant et de sa vue 
correspondante, tout en favorisant la coexistence de vues fondees sur diverses technologies. 
Le framework permet 1' utilisation d'un nombre important de technologies de presentation. 

La section suivante detaille la mise en ceuvre de Spring MVC dans l'etude de cas Tudu Lists. 

Tudu Lists : utilisation de Spring MVC 

Maintenant que les concepts et composants mis en oeuvre dans Spring MVC sont eclair- 
cis, nous pouvons passer a la description de la facon dont nous le mettons en pratique 
dans notre etude de cas. 

Pour Spring MVC, nous avons cree un projet, Tudu-SpringMVC, independant de celui 
fonde sur le framework MVC Struts, dont la migration est detaillee dans cette section. 
Ce projet etant aussi utilise au chapitre 13, qui necessite un fournisseur JMS actif, il 
faut executer le script build. xml, comme indique au chapitre 1, avant de lancer 
1' application Web. 

Configuration des contextes 

Le premier contexte renvoie a 1' application Web. II est charge avec le support de la classe 
ContextLoaderLi stener en utilisant les fichiers dont le nom correspond au pattern /WEB- 
INF/applicationContext* .xml. 

Le second contexte est utilise par Spring MVC. II est charge par la servlet DispatchSer- 
vlet en utilisant le fichier WEB-INF/action-servlet.xml. Les differentes entites relatives 
a Spring MVC sont definies dans ce fichier. 

La migration a done un impact sur le fichier web.xml puisque la servlet configured est 
remplacee : 

<?xml version="1.0" encoding="UTF-8"?> 
<web-app> 
(...) 
<servl et> 
<servlet-name>action</servl et-name> 
<servl et-cl ass> 

org. springframework. web. servlet. DispatcherServlet 
</servl et-cl ass> 

<1 oad-on-startup>K/l oad-on-startup> 
</servl et> 



<servlet-mapping> 
<servl et-name>action</servl et-name> 
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<url -pattern>*.action</url -pattern> 
</servlet-mapping> 
(...) 

</web-app> 

Dans le cadre de la migration, les fichiers du contexte principal restent inchanges. 
Commons Validator 

Le projet Spring Modules offre le support de Commons Validator, le framework de la 
communaute Apache Jakarta visant a specifier les regies de validation par declaration et 
communement utilise avec Struts. 

Commons Validator se configure de la maniere suivante : 

<bean id="validatorFactory" class="org.springmodules. commons 

. val idator .Defaul tVal i da tor Factory "> 
<property name="val idationConfi g Locations'^ 
<list> 

<val ue>/WEB- INF/ val idator- rul es.xmK/val ue> 
<value>/WEB-INF/validation.xml</val ue> 
</list> 
</property> 
</bean> 

<bean id="beanValidator" class="org.springmodules. commons 

.val idator.DefaultBeanValidator"> 
<property name="validatorFactory" ref="validatorFactory"/> 
</bean> 

Dans chaque controleur de gestion de formulaire, la propriete validator doit etre ensuite 
positionnee avec le Bean beanVal idator. Ce dernier utilise la valeur de la propriete command- 
Class afin de determiner le nom du bloc form dans la configuration de la validation WEB- 
INF/validation.xml. La reprise des regies de validation devient de la sorte possible. 



Implementation des contrdleurs 

Au travers de Struts, les controleurs sont implemented par le biais de la classe 
org. apache. struts. action. Action. Plusieurs types d'actions permettent deresoudre diverses 
problematiques. 

Le tableau 7.1 fournit la correspondance entre les actions de Struts et les controleurs de 
Spring MVC suivant la problematique a resoudre. 



Tableau 7.1. Correspondance entre les actions Struts et les controleurs Spring MVC 



Problematique 


Action Struts 


Controleur Spring MVC 


Controleur simple 


Action 


Controller 


Controleur multiple 


DispatchAction 


MultiActionController 


Controleur avec gestion 


Action ou DispatchAction avec 


Simpl eFormControl 1 er avec un Bean inde- 


de formulaire 


une instance d'ActionForm 


pendent 
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La section suivante se penche sur la facon de migrer deux actions realisant respective - 
ment un affichage de donnees et une gestion de formulaire. La presentation associee a ces 
deux controleurs utilise les technologies JSP/JSTL. 

Controleur simple 

Ladaptation de Taction ShowTodosAction du package tudu.web permet d'afhcher les todos 
d'une liste. La migration consiste a realiser les modifications suivantes (voir le code ci- 
apres) : 

• Implementation de l'interface Controller du package org.springfra- 
mework.web.servlet.mvc (repere Q). Comme nous l'avons vu precedemment, les traite- 
ments presents dans la methode execute se trouveront desormais dans la methode 
handleRequest (repere Q). 

• Modification de la facon d'ajouter les elements dans le modele (reperes Q et Q). 
Contrairement a Struts, Spring MVC les stocke dans une table de hachage et n'utilise 
pas les API servlet. 

• Modification de la facon de specifier la vue a utiliser. Spring MVC necessite unique- 
ment l'utilisation d'une instance de la classe Model AndView contenant l'identifiant de la 
vue et le modele (repere ©). La vue est configuree avec 1' implementation du View- 
Resol ver. 

• Configuration du controleur et de la vue utilisee. 

public class ShowTodosController implements Controller {<~0 
(...) 

public ModelAndView handl eRequest(HttpServl etRequest request, 
HttpServl etResponse response) throws Exception (<-© 

log.debugCExecute show action"); 

Collection<TodoList> todoLists = new TreeSet<TodoList>( 
userManager.getCurrentUser( ) .getTodoListst ) ) ; 

Map<String,Object> model^new HashMap<String,Object>( ) ;<-© 
if ( ItodoLi sts . isEmptyt ) ) { 
String listld = 

RequestUtil s .getStringParameter (request , "listld"); 
if (listld != null) { 

model .putt "defaul tList" , 1 istld) ;<-© 
} else { 

model .putCdefaultList", 

todoLists. iterator ( ) .next( ) .get Li stld( ) ) ;<-© 

} 

} 

return new ModelAndViewC'todos", model );<-© 

} 

} 
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Le controleur se configure dans le fichier WEB-INF/action-servlet.xml. Avec Spring 
MVC, les configurations des proprietes relatives au MVC et la resolution des dependances 
sont realisees dans ce fichier : 

<bean id="showTodosController" 

cl ass="tudu.web.ShowTodosControl 1 er"> 
<property name="userManager" ref="userManager" /> 
</bean> 

La maniere d'acceder au controleur est definie dans le meme fichier en ajoutant une 
entree dans la propriete mapping de la configuration de la strategie de mappage. Afin de 
conserver les memes URI pour les differents traitements, nous avons choisi l'implemen- 
tation SimpleUrlHandlerMapping, qui minimise l'impact sur les vues. 

Pour le controleur showTodosController, l'entree /secure/showTodos . acti on doit etre ajou- 
tee : 

<bean id="handlerMapping" class="org.springframework.web 

.servlet. handler. Si mpleUrlHandlerMapping"> 
<property name="inappings"> 
<props> 
(...) 

<prop key="/secure/showTodos .acti on "> 

showTodosController 
</prop> 
(...) 
</props> 
</property> 
</bean> 

Cette etude de cas met egalement en pratique le mecanisme de chainage de Vi ewResol ver. 
Ainsi, retrouve-t-on dans le fichier WEB-INF/action-servlet.xml la configuration de 
plusieurs ViewResol ver : 

• Le premier est implements par la classe ResourceBundleViewResolver, qui utilise le 
fichier de proprietes views .properties afin de configurer les vues. 

• Le deuxieme est implements par la classe Xml Vi ewResol ver, qui utilise le fichier WEB- 
INF/views.xml pour configurer les vues. 

• Le dernier est implements par la classe Internal ResourceVi ewResol ver, qui se fonde 
dans notre cas sur une vue JSP/JSTL. II constitue la strategie de resolution par defaut 
et est utilise dans le cas ou un identifiant de vue ne peut etre resolu par les deux entites 
precedemment decrites. 

La figure 7.11 illustre cette chaine en soulignant les identifiants des vues configurees 
dans les deux premiers ViewResol ver. 

Le controleur utilise la vue todos qui est resolue par le dernier Vi ewResol ver et correspond 
done a la page JSP todos.jsp localisee dans le repertoire WEB-INF/jsp/. Dans le cas 
d'une migration vers Spring MVC, aucune modification n'est necessaire dans cette page. 
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Figure 7.11 

Chainage des ViewResolver dans Tudu Lists 



Controleur de gestion d'un formulaire 

La migration d'une entite de gestion d'un formulaire est plus complexe, les mecanismes 
correspondants etant opposes a ceux de Struts. Arretons-nous un instant sur 1' adaptation 
de Taction MylnfosAction du package tudu. web, qui permet de modifier les informations 
d'un utilisateur de l'application. 

La migration consiste a realiser les modifications suivantes (voir le code ci-apres) : 

• Etendre la classe Simpl eFormControl 1 er. Avec Spring MVC, la gestion d'un formulaire 
ne peut etre realisee avec un controleur a entree multiple tel que Multi Acti onControl 1 er 
(repere ©). 

• Surcharger la methode formBackingObject afin de charger les donnees du formulaire 
(repere Q). 

• Redefinir la methode onSubmit afin de traiter les donnees soumises par le formulaire 
(repere Q) avec la methode HTTP POST. 

• Specifier et configurer la validation des donnees soumises. La migration utilise 
Commons Validator ainsi que les memes regies de validation. 

• Configurer le controleur ainsi que les vues utilisees. 

public class MylnfoControl 1 er extends Simpl eFormControl 1 er {<-© 
(...) 

protected Object formBackingObject(HttpServletRequest request) 

throws ServletException 
String login = request. getRemoteUser( ) ; 
User user = userManager.findllser(login) ; 
UserlnfoData data=new UserInfoData( ) ; 
data .set Pas sword (user .get Password ( ) ) ; 
data .setVerify Password (user .get Pas sword ( ) ) ; 
data .set Fi rstName( user. get Fi rstNamet ) ) ; 
data .set Last Name (user .get Las tNamet ) ) ; 
data .set Emai 1 (user. get Emai 1 ( ) ) ; 
return data; 

} 



protected Model AndView onSubmit(HttpServletRequest request, 
HttpServletResponse response, Object command, 
BindException errors) throws Exception {<-© 
UserlnfoData data = (UserlnfoData) command; 
String password = data.getPasswordO; 
String firstName = data .getFi rstNamet ) ; 
String lastName = data.getLastName( ) ; 
String email = data .getEmai 1 ( ) ; 
String login = request. getRemoteUsert ) ; 
User user = userManager.findUser(login) ; 
user. set Password (password) ; 
user .set Fi rstNamet fi rstName) ; 
user. set LastName (lastName) ; 
user.setEmail (email ) ; 
userManager.updatellser(user) ; 
return showForm( request , response, errors) ; 

} 

} 

Comme pour le controleur precedent, le controleur MylnfoController doit etre configure 
dans le fichier action-servlet.xml de la maniere suivante : 

<bean id="myInfoControl 1 er" cl ass="tudu.web.MyInfoControl 1 er"> 
<property name="userManager" ref="userManager" /> 
<property name="formView" val ue="user_info"/> 
<property name="val idator" ref="userInfoVal idator"/> 
<property name="commandName" value="userinfo"/> 
<property name="commandCl ass" 

val ue="tudu. web. bean. User InfoData"/> 

</bean> 

Une entree doit egalement etre ajoutee au Bean handlerMapping arm que le controleur 
puisse etre accede a partir d'un URI : 

<bean id="handlerMapping" class="org.springframework.web 

.servlet. handler. Si mpleUrlHandlerMapping"> 
<property name="mappings"> 
<props> 
(...) 

<prop key=" /secure/my Info. act i on "> 

mylnfoControl 1 er 
</prop> 
(...) 
</props> 
</property> 
</bean> 

Les donnees du formulaire soumises peuvent etre validees par le biais de 1' abstraction 
Val idator vue precedemment, et plus particulierement les implementations constituant le 
support de Commons Validator, qui permet de reutiliser les regies de validation userinfo. 
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Le controleur utilise la vue userjnfo dans le but d'afficher le formulaire dans les cas 
d'echecs ou de succes lors de la validation. Cette vue est resolue par le dernier Vi ewResol - 
ver de la chaine et correspond done a la page JSP user_info. jsp localisee dans le reper- 
toire WEB-INF/jsp/. Cette page doit etre modifiee afin de remplacer les taglibs de 
gestion des formulaires de Struts par ceux de Spring MVC. 

Le framework met en oeuvre le taglib bind afin de remplir les champs du formulaire et 
d'afficher les eventuelles erreurs de validation, comme dans le code suivant : 

(...) 

<spring:bind path="userinfo"> 
<font color="red"> 
<bXc:out val ue="$ ( status . val ue}"/X/b> 
<b><c:out val ue="$ { status .errorMessage}"/X/b> 
</font> 
</spring:bind> 

<form action="<c:url val ue="/secure/myInfo.action"/>" 

method="POST" focus="fi rstName"> 

(...) 

<spring:bind path=" userinfo.fi rstName"> 
<input type="text" name="f i rstName" 

val ue="<c:out val ue="${ status . val ue} "/>" 
size="15" maxl ength="60"/> 
 <font color="red"> 

<c:out val ue=" ${ status .errorMessage}"/> 
</font> 
</spring:bind> 
(...) 

<input type=" submit" val ue="<fmt:message key="form.subinit"/>"/> 
<input type="button" 

oncl i c k= " document. 1 oca ti on. href='<c:url 

value=". . /welcome. act i on "/>' ;" 
value="<fmt:message key="form. cancel "/>"/> 
</form> 

Le controleur affiche la page de formulaire suite au succes de la soumission des donnees 
par l'appel de la methode showForm dans la methode onSubmit. Lutilisation d'une autre 
vue grace aux methodes setSuccessView et getSuccessView serait aussi possible. 



Implementation de vues specif iques 

Tudu Lists utilise plusieurs technologies de presentation afin de generer differents 
formats de sortie (HTML, XML, RSS, PDF). Spring MVC offre une infrastructure faci- 
litant leur utilisation conjointement dans une meme application. 

Dans la mesure oil le Vi ewResol ver utilise precedemment pour les vues utilise les techno- 
logies JSP et JSTL, il ne peut servir pour les vues decrites ci-dessous. Dans les sections 
suivantes, nous utilisons 1' implementation XmlVi ewResol ver afin de les configurer. 
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XML 

L' application Tudu Lists permet de sauvegarder au format XML les informations conte- 
nues dans une liste de totos. Cette fonctionnalite est implementee par l'intermediaire du 
controleur BackupTodoListControl ler du package tudu. web, qui a la responsabilite de char- 
ger la liste correspondant a 1'identifiant specifie puis de la placer dans le modele afin de 
la rendre disponible lors de la construction de la vue. 

Ce controleur dirige les traitements a la vue ayant pour identifiant backup a la fin de ses 
traitements. Cette derniere, implementee par la classe BackupTodoListView du package 
tudu. web, estresolue par le second ViewResolver de la chaine. 

Sa configuration se trouve dans le fichier views.xml localise dans le repertoire WEB- 
INF. Elle utilise le support de la classe AbstractXsltView de Spring MVC afin de generer 
une sortie XML, comme le montre le code suivant : 

public class BackupTodoListView extends AbstractXsltView { 
(...) 

protected Source createXsl tSourcet 

Map model, String root, HttpServl etRequest request, 
HttpServletResponse response) throws Exception { 

TodoList todoList = (TodoList)model .get( "todoList" ) ; 
Document doc = todoListsManager.backupTodoList(todoList); 
return new D0MSource( new D0M0utputter( ) .output( doc ) ); 

} 

} 

A la fin de l'execution de la methode createXsl tSource, la classe BackupTodoListView rend 
la main a sa classe mere afin de realiser une transformation XSLT et d'ecrire le contenu 
sur le flux de sortie. 

L'utilisation de Xml ViewResolver permet d'injecter une instance du composant TodoLists- 
Manager dans la classe de la vue et de specifier le fichier backup.xsl en tant que feuille de 
style XSLT, comme decrit dans le fichier views.xml suivant : 

<bean id="backup" class="tudu.web.BackupTodoListView"> 

<property name="styl esheet Location" 

val ue="/WEB- I NF/xsl /backup.xsl "/> 

<property name="todoLi stsManager" ref="todoLi stsManager"/> 
</bean> 

PDF 

L' application de l'etude de cas permet egalement de generer un rapport au format PDF 
avec les informations contenues dans une liste de todos. Cette fonctionnalite est imple- 
mentee par l'intermediaire du controleur ShowTodoListsReportController du package 
tudu. web, qui a la responsabilite de charger la liste correspondant a l'identifiant specifie 
puis de la placer dans le modele afin de la rendre disponible lors de la construction de la 
vue. 
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Ce controleur dirige les traitements vers la vue ayant pour identifiant todojl 1 sts_report a 
la fin de ses traitements. Cette vue, implemented par le biais de la classe ShowTodoLists- 
PdfView du package tudu.web, est resolue par le second ViewResol ver de la chaine. 

Sa configuration se trouve dans le fichier views.xml localise dans le repertoire WEB- 
INF. Elle utilise le support de la classe AbstractPdfView de Spring MVC afin de generer 
une sortie PDF par le biais du framework iText, comme le montre le code suivant : 

public class ShowTodoListsPdfView extends AbstractPdfView { 

protected void bui 1 dPdf Document( 
Map model, Document doc, 
PdfWriter writer, HttpServl etRequest req, 
HttpServl etResponse resp) throws Exception { 

TodoList todol_ist=(Todol_ist)model . get( "todol 1st") ; 

doc. add (new Paragraph(todol_ist.getl_istId( ) ) ) ; 
doc. add (new Paragraph(todoList.getName( ) ) ) ; 
(...) 

} 

} 

La classe mere de la classe ShowTodoListsPdfView a la responsabilite d'instancier les diffe- 
rentes classes de iText afin de les lui fournir. A la fin de l'execution de la methode bui 1 - 
dPdf Document, la classe ShowTodoListsPdfView rend la main a sa classe mere pour ecrire le 
contenu sur le flux de sortie. 

Cette vue aurait pu aussi bien etre configured dans le fichier views.properties, car elle ne 
necessite pas d'injection de dependances. 



Conclusion 

Spring et son framework MVC ont su tirer parti des limitations d'autres frameworks 
MVC tels que Struts. La modularite, l'isolation des differents composants du pattern MVC 
ainsi que l'ouverture du framework sont les objectifs vises. Des lors, le developpement 
des applications utilisant differentes technologies est facilite, de meme que le changement 
de briques sans impact sur le reste de l'application et l'extension du framework. 

Lutilisation de l'injection de dependances de Spring dans 1' implementation du pattern 
MVC offre une reelle facilite de configuration de ces differents composants ainsi que de 
leurs dependances. Cette configuration se trouve centralisee dans le contexte d' applica- 
tion de Spring, lequel peut de la sorte mettre a disposition toute la puissance du conteneur 
leger. 

Spring MVC propose en outre des implementations robustes de controleurs visant a 
resoudre les problematiques techniques des applications Web. Dans le cadre de la gestion 
des formulaires, le framework affiche une grande flexibilite d'utilisation et de validation des 
donnees du formulaire. 
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Le framework Spring MVC offre enfin une separation claire entre le controleur et la vue 
ainsi qu'un support pour les differentes technologies et frameworks de presentation. 

En resume, ce framework fournit un socle solide pour developper des applications Web 
sans toutefois donner la possibility d'abstraire la navigation et l'enchainement des pages. 
Un framework tel que Spring Web Flow, presente en detail au chapitre suivant, peut 
s'appuyer sur ce socle afin de resoudre cette problematique. 
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Certaines applications Web necessitent un enchainement defini d'ecrans afin de realiser 
leurs traitements. Elles doivent, de plus, empecher l'utilisateur de s'ecarter des enchaine- 
ments possibles et garder un contexte relatif a 1' execution. Lorsque notre application 
repond a ces criteres, la mise en oeuvre d'outils tels que Spring Web Flow est pertinente. 
Ce type de framework ne presente en revanche aucun interet dans le cas d' applications 
pour lesquelles la navigation est libre. 

Le framework Spring Web Flow se positionne en concurrent direct de la fonctionnalite 
Page Flow du framework Beehive d' Apache, qui vise egalement a resoudre cette proble- 
matique. Les mises en oeuvre different cependant puisque le choix de Beehive porte sur 
l'utilisation massive des annotations alors que Spring Web Flow s'appuie sur des fichiers 
de configuration XML ou une API de definition des flots. 

Concepts des Web Flows 

L'objectif des Web Flows est d'implementer le traitement de flots Web qui comprennent 
plusieurs etapes et diverses contraintes pour passer d'une page a une autre. 

Dans le cas d' applications J2EE, ces etapes se materialisent par des interactions avec le 
serveur J2EE. 

La conception et la mise en oeuvre d' applications pour lesquelles la navigation se trouve 
restreinte et predefinie par des regies precises se revelent particulierement complexes, et 
ce pour les raisons suivantes : 

• La configuration des enchainements de traitements est difficile. 

• La verification de la validite des enchainements est complexe a mettre en oeuvre. 
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• La session HTTP n'est pas entierement adaptee pour stacker les donnees d'un ftat de 
traitements. 

• La reutilisation des differents flots Web est complexe a implemented 

Ces constats mettent en exergue les enjeux suivants, que 1' architecture et la conception 
de ce type d' application doivent resoudre de maniere optimale : 

• decouplage des flots et de leur implementation ; 

• gestion des donnees des etats du flot de traitements ; 

• respect des contraintes du flot par une entite autonome ; 

• favorisation de la reutilisation des flots Web ; 

• integration des flots Web dans l'environnement technique existant. 

Pour resoudre ces problematiques et adresser au mieux les enjeux precedemment decrits, 
l'approche adequate consiste a integrer un moteur d'execution de flots Web utilisant une 
description des flots. 

L utilisation de ce type de moteur dans une application offre les avantages suivants : 

• definition centralisee des elements du flot et de leurs enchainements ; 

• configuration du flot fondee sur une grammaire XML dediee, lisible aussi bien par un 
concepteur, un developpeur ou un environnement de developpement (IDE) ; 

• notion de transitions mise en ceuvre dans la configuration du flot afin de cadrer et secu- 
riser la navigation ; 

• gestion systematique par le moteur des etats en interne ; 

• suppression des dependances avec la technologie sous-jacente et le protocole utilise ; 

• configuration des flots facilement integrable dans un IDE ; 

• gestion du cycle de vie du flot facilitee et integree au moteur sans aucun impact sur les 
flots Web. 

Detaillons maintenant plus en detail les problematiques liees aux flots et automates a 
etats finis ainsi que leurs diverses composantes. 



Definition d'un flot Web 

Un flot Web s'inscrit dans la problematique generale des AEF (automate a etat fini). Ces 
automates permettent de specifier les differents etats accessibles des flots ainsi que la 
maniere de passer des uns aux autres. lis peuvent etre facilement decrits en UML dans 
des diagrammes d'activite avec des entites stereotypees, comme l'illustre la figure 8.1. 

Un flot est done caracterise par un ensemble fini d'etats possibles, dont certains peuvent 
etre initiaux et d'autres finaux. Lexecution ne peut se poursuivre que par le biais de tran- 
sitions d'un etat vers une liste d'etats connue et finie. 
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Figure 8.1 

Diagramme UML d'unflot Web 



Les etats initiaux et finaux exceptes, un etat est accessible depuis un ensemble d' etats 
suite au declenchement de differents evenements et peut transiter vers d' autres etats suite 
au declenchement d' autres evenements. 

La figure 8.2 illustre les differentes composantes d'un etat. 
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Le passage d'un etat a un autre s'effectue par le biais d'une transition, qui decrit I'etat a 
acceder suite au declenchement d'un evenement sur un autre etat. Propriete d'un etat, 
une transition regroupe l'evenement declencheur ainsi que I'etat a executer dans ce cas. 
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Les types d'etats 

Au sein d'un flot d'execution, plusieurs types d'etats peuvent etre mis en oeuvre afin 
d'adresser differentes problematiques : 

• Debut et fin. Les etats de debut et de fin d'un flot correspondent a des etats particuliers. 
Un etat de debut ne peut avoir d'etat 1' appelant, et un etat de fin ne doit pas posseder de 
transition en sortie. Ces types d'etats peuvent aussi bien etre des etats d'affichage de vue 
que de declenchement d' actions, ne possedant done pas de stereotype specifique. 

• Affichage de vue. Un etat peut correspondre a l'affichage d'une vue. II doit dans ce cas 
lui faire reference. Les differents evenements declenches par la vue doivent etre definis 
sur l'etat en tant que transitions. Ce type d'etat est designe par le terme « View State ». 
Nous utilisons le stereotype Vi ew State pour le representer. 

• Execution d'action. Un etat peut correspondre au declenchement d'une methode 
d'une action, quel que soit son type. II doit en ce cas definir les differents evenements 
a declencher que peuvent retourner ces methodes. Ce type d'etat est designe par le 
terme « Action State ». Nous utilisons le stereotype Action State pour le representer. 

• Aiguillage. Un etat peut correspondre a un aiguillage fonde sur une ou plusieurs 
conditions afin d'acceder a d'autres etats. Ce type d'etat est designe par le terme 
« Decision State ». Nous utilisons le stereotype Deci si on State pour le representer. 

• Lancement de sous-flots d'execution. Un etat peut declencher l'execution d'un sous- 
flot de traitement et permettre le passage de parametres d'un flot a un autre. Ce type 
d'etat est designe par le terme « Sub Flow State ». Nous utilisons le stereotype Sub Fl ow 
State pour le representer. 



Nous avons decrit dans cette section les differents concepts des flots Web dont Spring 
Web Flow constitue une implementation. Nous avons egalement aborde les notions d'etat 
et de transition utilisees dans ces flots. 

Les sections suivantes decrivent les mecanismes du framework Spring Web Flow permettant 
d'implementer cette problematique. 



Spring Web Flow n'est pas integre pour le moment dans la distribution de Spring. II 
correspond a l'un de ses sous-projets, dont les differentes versions sont telechargeables a 
l'adresse suivante : 



La page d'accueil du projet est quant a elle accessible par le biais du wiki du projet 
Spring, a l'adresse suivante : 




En resume 



Mise en oeuvre de Spring Web Flow 



http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=148517 



http://opensource2.atlassian.com/confluence/spring/display/WEBFLOW/Home. 
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Spring Web Flow offre une implementation afin de resoudre les problematiques decrites 
dans les sections precedentes. II fournit pour cela un niveau d' abstraction ainsi que diffe- 
rentes entites permettant de concevoir et d'implementer de maniere optimale des flots Web. 

La figure 8.3 illustre 1' architecture general e de Spring Web Flow. 



Figure 8.3 
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Les sections qui suivent detaillent la configuration de Spring Web Flow ainsi que la 
conception et 1' implementation des flots Web fondes sur ce framework. 



Configuration du moteur 

Spring Web Flow s'abstrait des frameworks MVC sous-jacents et fournit differents 
supports pour utiliser son moteur avec divers frameworks MVC. 

La configuration de ce moteur differe suivant que nous utilisions Spring MVC ou Struts. 

Configuration avec Spring MVC 

La configuration du moteur s'effectue en deux etapes : 

1. Configuration de la servlet de Spring MVC, DispatchServlet, ainsi que des emplace- 
ments des configurations des divers contextes de Spring dans le fichier web.xml, 
localise dans le repertoire WEB-INF/ : 

<web-app> 

<display-name>SpringWebFl ow</displ ay-name> 

<context-param> 
<param-name>contextConf igLocation</param-name> 
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<param-val ue>WEB- I NF/appl icationContext*.xml </param-val ue> 
</context-param> 

<1 istener> 

<1 i stener-cl ass> 
org. springframework. web. context. Context Loader Listener 

</listener-class> 
</l i stener> 

<servl et> 

<servlet-name>action</servl et-name> 

<servlet-class> 
org. springframework. web. servlet.DispatcherServlet 

</servl et-cl ass> 
</servl et> 

<servlet-mapping> 

<servlet-name>action</servl et-name> 

<url -pattern>*. html </url -pattern> 
</servlet-mapping> 
</web-app> 

La configuration dans ce fichier est specifique non de Spring Web Flow mais de 
Spring MVC. Elle doit etre mise en oeuvre afin que le support de Spring MVC par 
Spring Web Flow soit utilise. 

2. Configuration du moteur de Spring Web Flow lui-meme. Spring Web Flow utilise un 
controleur Spring MVC dedie, implements par l'intermediaire de la classe Fl owControl - 
ler, localisee dans le package org. springframework. webflow. executor. mvc. Ce controleur 
represente le point d'entree permettant d'utiliser le moteur. II est rattache a un URI par 
le biais d'une implementation de l'interface HandlerMapping de Spring MVC. 

Ce controleur s'appuie sur une entite d'execution des flots utilisant un registre de stoc- 
kage des definitions des flots. 

L' entite d'execution correspond a une implementation de l'interface Fl owExecutor du package 
org. springframework. webflow. executor. Nous utilisons 1' implementation FlowExecutorlmpl du 
meme package. Pour sa part, le registre correspond a l'entite de stockage des definitions des 
flots et est initialise par l'intermediaire de la classe Xml Fl owRegi stryFactoryBean du package 
org. springframework. webflow. registry dans le cas de fichiers XML de definition. 

Notons qu'il est possible de specifier plusieurs noms de fichiers XML par l'intermediaire 
d'une expression reguliere ou d'une liste de noms. L'identifiant du flot correspond au 
nom du fichier dans lequel il est defini, sans tenir compte de 1' extension. 

Le code suivant illustre la configuration complete du moteur dans le fichier action- 
servlet.xml localise dans le repertoire WEB-INF/ : 

<bean id="urlMapping" class="org. springframework. web. servlet 

. handl er.Simpl eLIrl Handl erMapping"> 

<property name="mappings"> 
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<props> 

<prop key="/flow/todol ists. html ">f 1 owControl ler</prop> 
</props> 
</property> 
</bean> 

<bean name="fl owControl 1 er" cl ass="org.springf ramework.webf 1 ow 

. executor. mvc. Fl owControl ler"> 

<property name="flowExecutor" ref="flowExecutor"/> 

<property name="cacheSeconds" value="5"/> 
</bean> 



<bean id="flowExecutor" class="org. spring-framework. webflow 

. executor. Fl owExecutorlmpl "> 

<constructor-arg> 

<bean id="repositoryFactory" class="org.springframework 
.webflow. execution. repository. continuation 
.ContinuationFl owExecuti on Repository Facto ry"> 
<constructor-arg ref="f 1 owRegistry"/> 
</bean> 
</constructor-arg> 
</bean> 



<bean id="f 1 owRegi stry" class="org.springframework. webflow 

. registry .Xml Fl owRegi s try Factory Bean "> 
<property name="flowLocations"> 
<list> 

<value>/WEB-INF/flows-*.xml</value> 
</list> 
</property> 
</bean> 

La resolution des vues du flot est dans ce cas realisee avec les facilites de Spring MVC 
par le biais des implementations de ViewResolver configurees dans 1' application. 

Configuration avec Struts 

De meme que pour Spring MVC, la configuration du moteur de Spring Web Flow avec le 
framework Struts se realise en deux etapes : 

1. Configuration de la servlet Struts ActionServlet et des emplacements des configura- 
tions des differents contextes de Spring dans le fichier web.xml, localise dans le 
repertoire WEB-INF/ : 

<web-app> 

<display-name>SpringWebFl ow</displ ay-name> 



<context-param> 
<param-name>contextConf igl_ocation</param-name> 
<param-val ue>WEB- 1 NF/appl icationCon text .xml </param-val ue> 

</context-param> 
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<1 istener> 

<1 i stener-cl ass> 
org. springf ramework. web. context. Context Loader Listener 

</listener-class> 
</l i stener> 

<servl et> 

<servlet-name>action</servl et-name> 

<servlet-class> 
org. apache. st ruts. act ion. Act ionServlet 

</servl et-cl ass> 
</servl et> 

<servlet-mapping> 

<servlet-name>action</servl et-name> 

<url -pattern>*.do</url -pattern> 
</servlet-mapping> 
</web-app> 

La configuration dans ce fichier est specifique non de Spring Web Flow mais de Struts. 
Elle doit etre mise en ceuvre afin que le support de Struts par Spring Web Flow soit 
utilise. 

2. Configuration du moteur de Spring Web Flow lui-meme. Spring Web Flow fournit et 
utilise Taction de Struts FlowAction localisee dans le package org.springfra- 
mework.webflow. executor. struts. Cette action doit etre configuree dans le fichier 
struts-config.xml du framework localise dans le repertoire WEB-INF/, comme dans 
le code suivant : 

<struts-config> 
<form-beans> 

<form-bean name="actionForm" type="org. springf ramework 

.web. struts. SpringBindingActionForm"/> 

</form-beans> 

<action-mappings> 

<acti on path="/f 1 ows-todol i st" 
name="actionForm" 
scope="request" 

type="org.springframework.webf low. executor. struts. FlowAction"/> 

</action-mappings> 

</struts-config> 



Cette action Struts s'appuie sur la classe SpringBindingActionForm de Spring pour benefi- 
cier des mecanismes de binding, ou mappage de donnees de la requete, et de validation 
du framework Spring. 
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Cette action se fonde sur le gestionnaire d' execution des flots de Spring Web Flow et le 
recherche au moyen de la cle flowExecutor comme identifiant de Bean dans le contexte 
de Spring. 

La configuration de cette entite dans le fichier applicationContext.xml est la suivante : 
<bean id="flowExecutor" class="org.springframework. webflow 



<bean id="f 1 owRegi stry" class="org. spring-framework. webflow 

. registry .Xml Fl owRegi s try Factory Bean "> 
<property name="flowLocations"> 
<list> 

<value>/WEB-INF/flows-*.xml</value> 
</list> 
</property> 
</bean> 

Notons que la classe FlowAction recherche le Bean du gestionnaire d'execution dans le 
contexte de 1' application Web et non dans le contexte de Spring associe a Struts. 

Fichier XML de configuration de flots 

Spring Web Flow offre une grammaire XML pour decrire des flots d' execution en mode Web. 

Nous detaillons ci-apres les balises et attributs permettant de modeliser les differentes 
entites decrites precedemment. 

L identifiant du flot doit correspondre au nom du Bean qui le configure dans Spring par 
1' intermediate de la classe Xml FlowFactoryBean. 

La balise de base du flot est webflow, laquelle doit posseder l'attribut start-state afin de 
definir l'etat initial du flot. L identifiant du flot est determine par le nom du fichier dans 
lequel il est defini. II n'est done pas necessaire de le specifier sur cette balise. 

Le code suivant permet de definir un flot en utilisant le fichier DTD du framework, acces- 
sible depuis le site de Spring : 




</bean> 



<?xml version="1.0" encoding="UTF-8"?> 



<!D0CTYPE flow PUBLIC "-//SPRING//DTD WEBFLOW 1.0//EN" 

"http://www.springframework.Org/dtd/spring-webflow-l.0.dtd"> 



<flow start-state="start"> 

(...) 
</flow> 



Integration des frameworks de presentation 

Partie II 

Un flot peut contenir les differents elements suivants : 

• attributs permettant de lui specifier des proprietes ; 

• actions executees au demarrage du flot ; 

• elements specifiques aux developpeurs (etat fonde sur une vue, etat fonde sur une 
action, etc.) ; 

• actions executees a la fin du flot ; 

• entites de gestion des exceptions ; 

• definitions de flots. 

Le code suivant illustre la mise en oeuvre de tous ces elements : 

<f 1 ow start-state="startingPoint"> 
<attribute .../> 

<start-actions>( . . . )</start-actions> 
<-- definitions de nos etats --> 
<gl obal -transi tionsX . . . )</global -transitions) 
<end-actions>( . . . )</end-actions> 
<exception-handl er .../> 
<inl ine-f 1 ow>( . . . )</inl ine-flow> 
</flow> 

Les sections qui suivent decrivent, selon la grammaire XML de Spring Web Flow, la 
configuration des differents types d' etats des flots : transition, etat fonde sur une action, 
etat fonde sur une vue, etat de decision, etat d'execution d'un sous-flot et etat de fin de 
flot. 

Transitions 

D'une maniere generale, tous les types d'etats se doivent de definir les transitions 
possibles vers d'autres etats. lis possedent tous pour cela une ou plusieurs sous-balises 
transition. 

Ces dernieres peuvent se presenter sous la forme la plus simple possible afin de specifier 
l'etat a atteindre (attribut to) apres le declenchement d'un evenement (attribut on), 
comme 1' illustre le code suivant : 

transition on="success" to="show.todolists" /> 
<transition on="detail" to="todol i st" /> 

Spring Web Flow rend egalement possible 1' execution de traitements sur une transition 
en definissant une sous-balise action pour la balise transition. 

Le code suivant permetd'executerlamethode bindAndVal idate de Taction todoListAction 
sur 1' evenement save avant d' atteindre l'etat save.todolist : 

transition on="save" to="save.todol ist"> 

<action bean="todoListAction" method="bindAndValidate" /> 
</transition> 
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Cette fonctionnalite facilite la mise en oeuvre des formulaires dans un flot Web, comme 
nous le verrons plus loin. Nous verrons aussi a la section decrivant les entites de Spring 
Web Flow comment declencher un evenement afin de transiter vers un autre etat du flot. 

Dans les differents types d'etats decrits ci-apres, les noms des balises associees sont tous 
suffixes par -state. 

Spring Web Flow offre la possibility de definir des transitions globales, appliquees auto- 
matiquement a tous les etats. Ces transitions peuvent etre configurees directement au 
niveau du flot, comme dans l'exemple suivant : 

<flow (...)> 

(...) 

<global -transitions> 

<transition on="global Eventl" to="statel"/> 

<transition on="global Event2" to="state2"/> 
</global -transitions> 
</flow> 

Actions 

Dans le contexte de Spring Web Flow, une action correspond a des traitements qui 
peuvent etre executes au cours d'un flot. Elle peut etre declenchee aux differents 
moments suivants : 

• Demarrage d'un flot. 

• Moment oil le flot entre dans un etat. 

• Moment oil le flot sort d'un etat. 

• Moment oil le flot execute une transition. 

• Moment de la finalisation d'un flot. 

Une action est configuree par 1' intermediate de la balise action, dont les principales 
proprietes sont le nom, avec l'attribut name, le Bean utilise, avec l'attribut bean, et le nom 
de la methode du Bean utilise, avec l'attribut method. 

Proprietes generates d'un etat 

D'une maniere similaire a un flot, les differents etats de Spring Web Flow possedent les 
proprietes communes suivantes : 

• attributs permettant de lui specifier des proprietes ; 

• actions executees au demarrage du flot ; 

• transitions ; 

• actions executees a la fin du flot ; 

• entites de gestion des exceptions. 
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Ces proprietes peuvent etre configurees pour tous les types d'etats, comme le montre 
l'exemple de code suivant : 

<some-state id="stateld"> 
<attribute (...)/> 

<entry-actions>( . . . )</entry-actions> 
<transition .../> 

<exit-actions>( . . . )</exit-actions> 
<exception-handler (...)/> 
</some-state> 

Etat fonde sur une action 

Ce type d'etat correspond a l'execution d'une methode d'un objet Java. II est defini par le 
biais de la balise action-state, comprenant l'attribut id afin de specifier son identifiant. 

De par son type, cette balise contient une sous-balise acti on permettant de rattacher l'etat 
a l'une des methodes d'action, comme le montre le code suivant, tire du fichier flows- 
todolist.xml du repertoire WEB -INF/ : 

<action-state id="todol ist"> 

<action bean="todol_istAction" method="setupForm"/> 

<transition on="success" to="show.todolist n /> 
</action-state> 

La valeur de l'attribut bean de la balise action correspond a l'identifiant d'un Bean confi- 
gure dans le contexte de Spring. 

Etat fonde sur une vue 

Ce type d'etat est defini par le biais de la balise vi ew-state, qui comprend l'attribut i d afin 
de specifier son identifiant et l'attribut vi ew afin de relier l'etat a la vue qu'il doit afficher. 

Le code suivant est tire du fichier flows-todolist.xml du repertoire WEB-INF/ : 

<view-state id="show.todolist" view="todolist"> 

transition on="list" to="todol ists"/> 
transition on="save" to="save.todolist"> 

<action bean="todol_istAction" method="bindAndValidate"/> 
</transition> 

<transition on="todos" to="todos"/> 
transition on="end" to="end"/> 
</view-state> 

La valeur de l'attribut view de la balise view-state correspond a l'identifiant d'une vue. 
Ce dernier est resolu suivant les fonctionnalites de la technologie sous-jacente utilisee. 
Dans le cas de Spring MVC, il est resolu par 1' intermediate des implementations de 
l'interface ViewResolver (voir le chapitre 7). 
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Etat de decision 

Spring Web Flow permet de definir des elements d'aiguillage fondes sur une ou plusieurs 
conditions. Le framework fournit cet etat par le biais de la balise decision-state, qui 
comprend un attribut id correspondant a l'identinant de l'etat. 

Cette balise peut comporter une ou plusieurs sous-balises i f , afin de configurer les diffe- 
rents tests. La balise if comprend un attribut test pour definir la condition, un attribut 
then pour specifier l'identifiant de l'etat dans le cas d'une verification du test et un attribut 
optionnel el se pour specifier l'identifiant de l'etat dans le cas contraire. 

Le code suivant illustre la mise en ceuvre d'un tel etat : 

<decision-state i d=" i sTodol istRss"> 

<if test="${requestScope.todolist == null)" 

then="todol ist"/> 
<if test="${requestScope.todolist.rssAl lowed}" 
then="conf igureTodoListRss" 
el se="conf igureTodoList"/> 
</decision-state> 

Les conditions suivent la syntaxe OGNL et peuvent utiliser des variables du contexte 
d' execution du flot. 



OGNL (Object-Graph Navigation Language) 

OGNL est un langage fonde sur des expressions destine a positionner et recuperer les proprietes d'objets 
Java. II consiste a evaluer des expressions qui peuvent avoir la forme suivante : ${requestScope.todo- 
1 i st. rssAl lowed}. Le projet relatif au langage est accessible depuis les adresses http://www.ognl.org ei 
http://www.opensymphony.com/ognl/. 



Etat d'execution d'un sous-flot 

Les flots d'execution etant par essence reutilisables, il est possible de les faire interagir 
les uns avec les autres. Un flot principal peut appeler des sous-flots et, dans ce cas, 
suspendre son execution le temps de l'execution du sous-flot. 

Spring Web Flow fournit un etat a cet effet, defini par le biais de la balise subflow -state. 
Cette balise comprend un attribut id correspondant a l'identifiant de l'etat, ainsi qu'un 
attribut f 1 ow permettant de relier l'etat au flot a executer. 

Le code suivant est tire du fichier flows-todolist.xml, localise dans le repertoire WEB- 
INF/: 

<subf 1 ow-state id="todos" flow="flows-todo"> 
(...) 

transition on="show.end" to="todol ist"/> 
</subflow-state> 

La valeur de l'attribut i d correspond a un sous-flot defini pour le registre de stockage des 
definitions de flots. De ce fait, il fait reference a un fichier definissant un flot, dont le nom 
correspond a l'identifiant, suffixe par .xml. 
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Dans notre cas, l'identifiant fait reference a un riot defini dans le fichier flows-todo.xml, 
localise dans le repertoire WEB-INF/ : 

(...) 

<flow start-state="todos"> 

(...) 

</flow> 

Spring Web Flow offre la possibilite de mapper des attributs du contexte du ftot principal 
dans des attributs du contexte du sous-ftot, comme dans le code suivant : 

<subflow-state id="todos" f 1 ow="f 1 ows-todo"> 
<attribute-mapper> 

<input-mapping value="${requestScope.id}" as="todoListId" /> 
</attribute-mapper> 

<transition on="show.end" to="todol i st" /> 
</subflow-state> 

Etat de fin de flot 

Ce type d'etat permet de terminer un flot d'execution et de liberer toutes les ressources 
associees a son contexte d'execution. II est defini par le biais de la balise view-state, 
comprenant l'attribut id pour specifier son identifiant et l'attribut view pour relier l'etat a 
la vue qu'il doit afficher. 

Le code suivant est tire du fichier flows-todolist.xml, localise dans le repertoire WEB- 
INF/ : 

<end-state id="show.end" view="end" /> 



Implementation des entites 

Les differentes entites d'un flot Web a implementer sont les actions et les vues. 

Les actions correspondent a des classes Java particulieres, qui peuvent etre de differents 
types suivant la problematique a resoudre. Les vues peuvent quant a elles utiliser des 
technologies diverses, dependant du framework MVC utilise conjointement avec Spring 
Web Flow. 

Le contexte du flot 

Chaque methode d' action specifique de Spring Web Flow prend en parametre un 
contexte permettant d'acceder entre autres aux parametres de la requete et des attributs 
du flot. Ces mecanismes s'appuient principalement sur les interfaces RequestContext, 
ParameterMap et AttributeMap, toutes localisees dans le package org.springfra- 
mework.webf 1 ow. 

La figure 8.4 illustre les interfaces precedemment introduites ainsi que leurs methodes 
principales. 
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Figure 8.4 

Entites globules 
de Spring Web Flow 



«interface» 
RequestContext 



+getFlowScope() : AttributeMap 
+getRequestParameters() iParamet 
+getRequestScope() : AttributeMap 



« interface" 
ParameterMap 



+get() : String 



1 


« interface" 
AttributeMap 


1 


+get() . Object 
+put() : void 



Comme le montre le code suivant, toutes les methodes d'actions utilisables dans un flot 
Web prennent en parametre un objet de type RequestContext afin d'avoir acces aux infor- 
mations des differents scopes et de l'evenement declencheur : 

public Event myMethod( RequestContext context) throws Exception { 
//Recuperation d'un parametre de la requete 
ParameterMap parameters = context. getRequestParameters( ) ; 
String myParameter=(String)parameters.get ("myParameter") ; 

//Recuperation d'un attribut dans le scope du flot 

AttributeMap attributes = context. getScopeFlowO; 

String my Attributed String) attributes, get ( "myAtt ri bute" ) ; 

(...) 

} 

Ces methodes retournent un objet de type Event afin de specifier l'evenement qui doit etre 
pris en compte lors de la transition, comme dans le code suivant : 

public Event myMethod( RequestContext context) throws Exception { 
(...) 

//Retourne par exemple l'evenement « success » 
return successO; 

} 

Le type Action 

II existe trois types d'actions principaux, les actions simples, les multiactions et les 
actions de gestion de formulaires. 

L' action ayant pour nom Action correspond a la forme la plus simple d'action ainsi qu'a 
1' abstraction de base de toutes les actions. Ces dernieres doivent necessairement l'imple- 
menter. Localisee dans le package org.springframework.webflow, elle possede un unique 
point d'entree, comme l'illustre le code suivant : 

public class Action { 

public Event executetRequestContext context) throws Exception; 



Integration des frameworks de presentation 

Partie II 



La methode de 1' interface prend en parametre le contexte courant du fiot execute et 
renvoie un evenement permettant de determiner la transition vers Taction suivante. 

Spring Web Flow fournit, en complement de cette interface, la classe AbstractAction du 
package org. springframework.webflow. action. Cette classe correspond a une implementa- 
tion abstraite de base permettant d'utiliser et d'implementer des actions. Elle dispose 
notamment des methodes retournant des evenements predefinis et tres souvent utilises, 
comme le recapitule le tableau 8.1. 



Tableau 8.1. Evenements predefinis par la classe AbstractAction 



Identifiant de 
I'evenement 


Methode 


Description 


success 


Event successO 

Event successtObject result) 

Event successtString resultParameterName, Object result) 


Evenement correspondant au 
succes d'un traitement 


error 


Event error () 

Event errortException e) 


Evenement correspondant a 
une erreur lors d'un traitement 


yes 


Event yes( ) 

Event yesOrNotbool ean booleanResult) 


Evenement correspondant a 
une affirmation 


no 


Event no() 

Event yesOrNotbool ean booleanResult) 


Evenement correspondant a 
une negation 



Event resulttString eventld) Construction personnalisee 

Event resulttString eventld. Map parameters) d'evenements a partir d'un iden- 

Event resulttString eventld. String parameterName, tifiant 

Object parameterVal ue) 



La classe AbstractAction fournissant sa propre implementation de la methode execute, le 
developpeur peut utiliser les methodes suivantes : 

• doPreExecute, qui permet d'executer des traitements avant l'eventuelle execution de 
la methode doExecute. Si la methode doPreExecution renvoie un evenement non null, la 
methode doExecute n'est pas executee, et cet evenement est renvoye. 

• doExecute, qui permet d'implementer les traitements de Taction. 

• doPostExecute, qui permet d'executer des traitements apres la methode doExecute, a 
moins qu'une exception n'ait ete levee dans celle-ci. 

Le code suivant met en oeuvre une action simple fondee sur la classe AbstractAction : 

public class MyAbstractAction extends AbstractAction { 
protected Event doPreExecutet 

RequestContext context) throws Exception { 
System. out. printing "Execution de la methode doPreExecute"); 
return nul 1 ; 

} 

protected Event doExecutet 

RequestContext context) throws Exception { 
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(...) 



protected void doPostExecute( 



RequestContext context) throws Exception { 



System. out. println( 



"Execution de la methode doPostExecute" ) ; 



Le type Multi Action 

Spring Web Flow fournit un type d' action plus evolue, permettant de definir plusieurs 
points d'entree. Ce mecanisme peut etre mis en relation avec la balise bean dans les 
fichiers XML de description de flots, laquelle supporte un attribut method afin de definir la 
methode a appeler sur Taction. 

Les points d'entree doivent etre de la forme suivante, oil myMethod est un nom de methode 
quelconque : 

public Event myMethod( RequestContext context) throws Exception { 



Lorsque l'attribut method n'est pas specifie, le framework utilise l'identifiant de l'action- 
state englobante comme nom par defaut de la methode a appeler. 

La classe de base de ce type d'action est Multi Action, localisee dans le package 
org. springframework.webflow. action. Cette classe etend la classe AbstractAction afin 
d'implementer les mecanismes de selection de la methode a appeler. 

Le code suivant met en oeuvre ce type d'action avec la classe TodoListsAction, localisee 
dans le package tudu.web de 1' application Tudu Lists : 

public class TodoListsAction extends MultiAction { 



public Event 1 istCRequestContext context) throws Exception { 

(...) 

return successO; 

} 

public Event detail (RequestContext context) throws Exception { 

(...) 

return successO; 

} 

public Event end( RequestContext context) throws Exception { 

(...) 

return successO; 

} 



(...) 



(...) 

} 
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Si nous considerons que l'instance de Taction ci-dessus est configured dans le contexte 
de Spring avec l'identifiant myMultl Action, l'etat utilisant cette action peut etre configure 
de l'une des deux manieres suivantes : 

<action-state id="test"> 

<action bean="myMulti Action" method="myMethod"/> 

(...) 
</action-state> 

Ou : 

<acti on-state id="myMethod"> 

<acti on bean="myMul ti Acti on"/> 

(...) 
</action-state> 

Utilisation de Beans en tant qu'actions 

Spring Web Flow offre la possibility d'utiliser n'importe quel Bean en tant qu'action. 
Dans ce cas, le composant n'a aucune adherence avec le framework. L'objectif de cette 
fonctionnalite est d'appeler directement une classe d'une application, telle qu'un service 
metier dans un flot Web. Ainsi, 1' implementation d'une action realisant simplement 
l'appel au Bean n'est plus necessaire. 

Spring Web Flow se charge de recuperer un objet dans un contexte du flot et de le passer en 
parametre de la methode. Si aucune erreur ne survient durant l'execution de cette methode, 
l'objet de retour est place dans le contexte avec une cle configured dans le flot, et un 
evenement success est renvoye. Dans le cas contraire, un evenement error est renvoye. 

Le code suivant donne un exemple de mis en oeuvre de cette fonctionnalite : 

<act ion-state id="searchTodos"> 

<action bean="searchTodosManager" 

method=" searchTodos (${flowScope.todoCriteria))" 
resul tName=" results "/> 
transition on="success" to="displayTodos"/> 
</action-state> 

Le Bean doit contenir une methode searchTodos, avec un parametre de type TodosCrite- 
ria, contenant les informations pour la recherche. Afin de garantir cette regie, le Bean 
peut implemented par exemple, 1' interface suivante : 

public interface SearchTodosManager { 

List searchTodosdodosCriteria criteria); 

} 

Le type FormAction 

Un des types d' actions les plus utilises est celui gerant les formulaires. II correspond a 
une specialisation du type d'action precedent par le biais de la classe FormAction du 
package org. spring-framework. webflow. action. II possede un cycle de vie de gestion inspire 
du framework Spring MVC, que nous allons detailler. 
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La classe FormAction fournit les differentes proprietes recapitulees au tableau 8.2. 



Tableau 8.2. Proprietes de la classe FormAction 



Methode 


Valeur par defaut 


Description 


FormObjectNarne 


f ormObject 


Definit le nom de I'objet representant le formulaire. 


FormObjectCl ass 


null 


Definit la classe de I'objet representant le formulaire. 


f ormObjectScope 


ScopeType. REQUEST 


Definit I'endroit de stockage de I'objet representant le formu- 
laire. 


ErrorsScope 


ScopeType. REQUEST 


Definit I'endroit de stockage de I'objet contenant les erreurs 
de validation d'un objet de formulaire. 


property Edi to r Registrar 


null 


Definit ['implementation de I'interface PropertyEditorRe- 
gistar afin d'enregistrer des PropertyEditor pour I'action. 
Ces enregistrements peuvent egalement etre realises en sur- 

nn a tn o^nt \a mciinnnQ lfiitRnnflor Ho 1 Option 
CMdiycdlll Id lllculUUc IMILDIrlutir ue 1 dUUUII. 


Val idator 


null 


Specifie I'instance du validateur a utiliser afin de valider I'objet 
representant le formulaire. 


bindOnSetupForm 


fal se 


Specifie si I'objet representant le formulaire doit etre rempli 
avec les parametres de la requete durant I'execution de la 
methode setupForm. 


val idateOnBinding 


true 


Specifie si I'objet representant le formulaire doit etre valide 
lors de son remplissage avec les parametres de la requete. 


messageCodesResol ver 


null 


Specifie la strategie a utiliser afin de convertir les codes 
d'erreurs en messages. 



La classe FormAction fournit six methodes predefinies pouvant etre appelees lors de 
I'execution du flot par le biais de la balise action. Le tableau 8.3 recapitule les fonctions 
de ces methodes predefinies. 



Tableau 8.3. Methodes predefinies de la classe FormAction 



Methode 


Description 


expose FormObject( Request Context) 


Charge I'objet representant le formulaire et le place dans le contexte tout en enre- 
gistrant les differents PropertyEditor. Retourne I'evenement success en cas du 
succes du chargement, et error dans le cas contraire. 


setupForm(RequestContext ) 


Se comporte de la meme maniere que la methode precedente en ajoutant la pos- 
sibility de realiser du binding, ou mappage, de donnees de la requete. La methode 
se comporte de la maniere concernant les evenements retournes. 


bindAndVal i date ( RequestCon text) 


Utilise les differents parametres de la requete afin de remplir I'objet de formulaire 
puis le valide en utilisant le validateur configure. Retourne I'evenement success s'il 
n'y a pas d'erreurs de binding ou de validation, et error dans le cas contraire. 


bind( Request Con text) 


Utilise les differents parametres de la requete afin de remplir I'objet de formulaire. 
Retourne I'evenement success s'il n'y a pas d'erreurs de binding, et error dans 
le cas contraire. 
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Tableau 8.3. Methodes predefinies de la classe FormAction (suite) 

validate(RequestContext) Valide I'objet de formulaire associe a Taction en utilisant le validateur configure. 

Retourne I'evenement success s'il n'y a pas d'erreurs de validation, et error dans 
le cas contraire. 

reset Form(RequestContext) Reinitialise I'objet de formulaire associe a Taction. Retourne I'evenement success 

si les traitements se passent bien, et error dans le cas contraire. 



L' utilisation de la classe FormAction se configure sur differentes entites d'un flot, 
puisqu'elle impacte forcement plusieurs etats. 

L'etat de vue affichant le formulaire ainsi que ses eventuelles erreurs doit initialiser 
correctement Taction puis specifier la methode de Taction a executer sur la transition, 
comme le montre le code suivant, tire du fichier flows-todolist.xml, localise dans le 
repertoire WEB-INF/ : 

<view-state id="show.todol ist" view="todol ist"> 

<action bean="todol_istAction" method="setupForm"/> 
<transition on="list" to="todol ists" /> 
<transition on="save" to="save.todolist"> 

<action bean="todoListAction" method="bindAndVal idate"/> 
</transition> 

transition on="todos" to="todos"/> 
<transition on="end" to="end"/> 
</view-state> 

L'etat save.todolist implemente une methode save afin de traiter les donnees du formu- 
laire, comme dans le code suivant, tire du meme fichier que precedemment : 

<action-state id="save.todolist"> 

<action bean="todoListAction" method="save"/> 

<transition on="success" to="todol ist"/> 
</action-state> 

La classe FormAction fournit egalement differentes methodes de gestion de son cycle de 
vie interne, qu'il est possible de surcharger afin de le personnaliser. Ces methodes princi- 
pals sont recapitulees au tableau 8.4. 



Tableau 8.4. Methodes surchargeables du cycle de vie de la classe FormAction 
Methode Description 

initBinder(RequestContext, Permet de configurer I'instance de DataBinder passee en parametre. L'objectif est 

DataBinder) d'enregistrer des ProrpertyEditor specifiques pour certaines proprietes de I'objet 

de formulaire. Cette methode est appelee par la methode createBinder, qu'il est 
eventuellement possible de surcharger afin de creer une implementation de Data- 
Binder personnalisee. 

loadFormObject(RequestContext) Permet de charger I'objet de formulaire. Par defaut, elle appelle la methode create- 

FormObject, qu'il est possible de surcharger, bien qu'il soit preferable de surcharger 
la methode 1 oadFormObject. 
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Contrairement a Spring MVC, la classe FormAction ne fournit pas de methode similaire a 
la methode referenceData afin de charger des donnees utilisees pour l'affichage d'un 
formulaire. Le developpeur doit l'implementer si necessaire afin de placer des donnees 
dans le scope du Hot et l'appeler explicitement dans un etat du flot Web. 

Le code suivant donne un exemple d' implementation de cette methode : 

public Event setupReferenceData( 

RequestContext context) throws Exception ( 
Scope requestScope = context. getRequestScope( ) ; 
requestScope.setAttributeC'refData" , myDao.loadDatat ) ) ; 
return successt ) ; 

} 

Dans le cas de Taction implementee par la classe TodoListAction, nous chargeons l'objet de 
formulaire a partir de la base de donnees. Nous devons pour cela surcharger la methode 
createFormObject et implementer une methode save afin de traiter les donnees du formulaire. 

Le code de cette classe est le suivant : 

public class TodoListAction extends FormAction { 

private TodoLi stsManager todoListsManager; 

public TodoListAction( ) { 

setFormObjectName( "todoList" ) ; 

set FormObjectCl ass (TodoLi st. class) ; 

set FormObjectScopeCScopeType. FLOW) ; 

} 

public Object createFormObjecttRequestContext context) 

throws Exception { 

String listld = (String)context 

. getSourceEventt ) .get Parameter ( "id" ) ; 
return todoListsManager .findTodo Li st(l istld) ; 

} 

public Event save( RequestContext context) throws Exception { 
TodoList todoList = (TodoList)context 

.getFl owScopet ) . getAttribute( "todoList" ) ; 
todoLi stsManager .updateTodo Li st (todoList) ; 
return successt); 

} 

(...) 

} 

Remarquons dans cet exemple qu'un parametre de requete pour un etat est accessible par 
le biais du contexte et de sa propriete sourceEvent, qui possede une methode nommee 
getParameter. L'objet de formulaire est de plus accessible sur le scope configure pour 
Taction. Dans notre cas, il s'agit du scope du flot accessible a partir du contexte et de sa 
propriete flowScope, qui met a disposition une methode nommee getAttribute. 
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Execution des f lots 

L' execution des flots se realise en utilisant le controleur configure pour les differents 
frameworks MVC. 

Pour demarrer un flot, le parametre f 1 otld doit etre utilise afin de specifier le flot choisi. 
L'appel par le biais, par exemple, de la balise HTML <a href ></a> se realise de la maniere 
suivante : 

I <a href="<c:url value="/flow/todol ists.html 

?_f1owId=flows-todolist"/>">Demarrage du flot </a> 

Par la suite, le contexte du flot doit etre precise conjointement avec Pevenement declen- 
che par P intermediate des parametres _flowExecutionKey et_eventld. L'appel par le biais, 
par exemple, de la balise HTML <a href></a> se realise de la maniere suivante : 

| <a href="<c:url value="/flow/todolists.html?_flowExecutionKey 

=${flowExecutionKey}&_eventId=l ist"/>">Mon 1 ien</a> 



Tudu Lists : utilisation de Spring Web Flow 

Telle qu'elle est developpee, 1' application Tudu Lists ne permet pas d'integrer facilement 
Spring Web Flow, car elle est fondee sur la technologie AJAX, qui n'est pas supportee 
pour le moment par le framework. C'est la raison pour laquelle nous utilisons un projet 
specifique, Tudu-WebFlow. 

Nous migrans done les fonctionnalites de gestion des listes de todos et des todos avec 
Spring Web Flow dans un sous-projet annexe et independant. Nous concevons a cet effet 
deux flots gerant respectivement les listes de todos et les todos. Ces flots sont utilises 
avec le moteur de Spring Web Flow fonde sur Spring MVC. lis utilisent les memes 
concepts, adaptes aux differentes entites concernees. 

Nous allons tout d'abord decrire les deux flots Web, puis nous implementerons les diffe- 
rentes actions des flots et les configurerons ainsi que le moteur. 



Conception des flots 

L' application se compose d'un flot principal, nomme flows-todolist, decrit dans le 
fichier flows-todolist.xml du repertoire WEB-INF, et d'un sous-flot nomme flows-todo, 
decrit dans le fichier flows-todo.xml, localise dans le meme repertoire. 

Le flot principal, f 1 ows -todol i st, correspond a un flot Web d'affichage et de modification 
des listes de todos, comme l'illustre la figure 8.5. La premiere etape consiste a afficher 
P ensemble des listes de todos pour un utilisateur. II est ensuite possible d' afficher le 
detail d'un des elements de cette liste afin de le modifier. A partir de ce detail, le flot peut 
passer la main au flot de gestion des todos. 
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Le code suivant fournit le contenu du fichier flows-todolist.xml, correspondant a la 
configuration du flot Web : 

<?xml version="1.0" encoding="UTF-8"?> 

<!D0CTYPE flow PUBLIC "-//SPRING//DTD WEBFLOW 1.0//EN" 

"http://www.springframework.0rg/cltd/spring-webflow-l.O.dtd"> 

<flow start-state="start"> 

<view-state id="start" view="start"> 

<transition on="todol i sts" to="todol i sts"/> 
</view-state> 

<action-state id="todol ists"> 

<action bean="todol_istsAction" method="list"/> 

<transition on="success" to="show.todol ists"/> 
</action-state> 

<view-state id="show.todol i sts" view="todol ists"> 

<transition on="detail" to="todolist"/> 

<transition on="end" to="end"/> 
</view-state> 

<action-state id="todol ist"> 

<action bean="todol_istAction" method="setupForm"/> 

transition on="success" to="show.todol ist"/> 
</action-state> 

<view-state id="show.todol i st" view="todol ist"> 
<transition on="list" to="todol ists"/> 
<transition on="save" to="save.todolist"> 
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<action bean="todol_istAction" 

method="bindAndVal idate"/> 
</transition> 

<transition on="todos" to="todos"/> 
transition on="end" to="end"/> 
</view-state> 

<act ion-state id="save. todol i st"> 

<action bean="todoListAction" method="save"/> 
<transition on="success" to="todol ist"/> 
</action-state> 

<subflow-state id="todos" f 1 ow="fl ows-todo"> 
<attribute-mapper> 
<input-mapping 

val ue="${requestScope. id} " as="todol_istId"/> 
</attribute-mapper> 

<transition on="show.end" to="todol i st"/> 
</subf 1 ow-state> 

<action-state id="end"> 

<action bean="todoListsAction" method="end"/> 
<transition on="success" to="show.end"/> 
</action-state> 

<end-state id="show.end" view="end"/> 
</flow> 

Le sous-flot flows-todo correspond a un flot Web d'africhage et de modification des 
todos, comme l'illustre la figure 8.6. Celui-ci peut etre appele depuis le flot principal. II 
suit le meme principe que le flot precedent, en affichant tout d'abord la liste des todos 
pour un identifiant de liste, puis en permettant l'affichage du detail d'un todo en vue 
d'une eventuelle modification. 

Le contenu du fichier flows-todo.xml correspondant a la configuration du flot Web est le 
suivant : 

<?xml version="1.0" encoding="UTF-8"?> 

<!D0CTYPE flow PUBLIC "-//SPRING//DTD WEBFLOW 1.0//EN" 

"http://www.springframework.Org/dtd/spring-webflow-l.0.dtd"> 

<flow start-state="todos"> 
<action-state id="todos"> 

<action bean="todosAction" method="l i st"/> 
transition on="success" to="show.todos"/> 
</action-state> 

<view-state id="show. todos" view="todos"> 
<transition on="detail" to="todo"/> 
<transition on="end" to="end"/> 
</view-state> 
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<action-state id="todo"> 

<action bean="todoAction" method="setupForm"/> 

<transition on="success" to="show.todo"/> 
</action-state> 

<view-state id="show.todo" view="todo"> 
<transition on="list" to="todos"/> 
<transition on="save" to="save.todo"> 

<action bean="todoAction" method="bindAndVal idate"/> 
</transition> 

<transition on="end" to="end"/> 
</view-state> 

<action-state id="save.todo"> 

<action bean="todoAction" method="save"/> 

<transition on="success" to="todo"/> 
</action-state> 

<action-state id="end"> 

<action bean="todosAction" method="end"/> 

<transition on="success" to="show.end"/> 
</action-state> 

<end-state id="show.end"/> 
</flow> 

Les deux flots s'appuient sur differents types d'etats, utilisant aussi bien des actions que 
des vues. 




« View State » 
end 



Figure 8.6 

Flot de gestion des todos 
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Implementation des entites 

Les differentes entites a implementer sont les actions et les vues. Concernant les vues, 
nous faisons le choix d'utiliser les technologies JSP et JSTL, ainsi que les fonctionnalites 
de gestion des vues du framework Spring MVC. 

Decrivons tout d'abord les differents types d' actions implemented. 
Les types d'actions 

Tudu Lists utilise des actions a entrees multiples et des actions de gestion de formulaires, 
afin d'adresser respectivement l'affichage des listes de todos et celui des todos, ainsi que 
leurs modifications. 

Les actions d'affichage des listes s'appuient sur une action de type Multi Action du 
package org.springf ramework.webf low. act ion. Multi Act ion. 

Prenons l'exemple de la classe TodoListsAction, localisee dans le package tudu. web et de 
sa methode list. Cette derniere charge la liste des todol i sts en utilisant une instance de la 
classe TodoListsManager injectee par Spring et la place dans le contexte du flot, comme 
dans le code suivant : 

public class TodoListsAction extends MultiAction { 

private UserManager userManager; 

private TodoListsManager todoListsManager; 

public Event listtRequestContext context) throws Exception { 

User user = userManager. getCurrentUser( ) ; 

Collection todoLists = user.getTodoListst ) ; 

context. getRequestScope( ) .put ("todoLists", todoLists) ; 

return success( ) ; 

} 



public UserManager getUserManagert ) { 
return userManager; 

} 



public void setUserManager(UserManager userManager) ( 
this. userManager = userManager; 

} 



public TodoListsManager getTodoLi stsManager( ) { 
return todoListsManager; 

} 

public void setTodoLi stsManagert 

TodoListsManager todoListsManager) { 
this. todoListsManager = todoListsManager; 

} 

} 

Tudu Lists utilise egalement des actions de gestion de formulaires afin de sauvegarder les 
modifications sur des entites telles que les listes de todos avec la classe TodoListAction, 
localisee dans le package tudu. web. Cette classe surcharge la methode createFormObject 
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afin de charger une instance de la classe TodoLi st a partir de la base de donnees et imple- 
mente une methode save afin de sauvegarder les modifications : 

public class TodoLi stActi on extends FormAction { 

private TodoLi stsManager todoListsManager; 

public TodoListAction( ) { 

setFormObjectName( "todoList" ) ; 

set FormObjectCl ass (TodoLi st. class) ; 

set FormObjectScope(ScopeType. FLOW) ; 



public Object createFormObject(RequestContext context) 

throws Exception { 

ParameterMap parameters = context. getRequestParameters( ) ; 

String listld = parameters. getC'id") ; 

return todoListsManager .findTodo Li st(l istld) ; 



public Event saveCRequestContext context) throws Exception { 

TodoList todoList = (TodoList)context 

.getFl owScope( ) . get( "todoLi st" ) ; 
todoLi stsManager .updateTodoListt todoLi st) ; 
return successO; 



public TodoListsManager getTodoListsManagert ) { 
return todoListsManager; 

} 

public void setTodoListsManager( 

TodoListsManager todoListsManager) { 
this. todoListsManager = todoListsManager; 

} 

} 

Notons que les proprietes sont configurees dans le constructeur de Taction mais qu'elles 
auraient tres bien pu l'etre dans le contexte applicatif de Spring. 

Les vues 

Puisque nous utilisons Spring MVC comme framework MVC, nous retrouvons les prin- 
cipes detailles a la section « Spring MVC et la gestion de la vue » du chapitre 7. 

La seule difference consiste dans l'appel du controleur de Spring Web Flow, qui requiert 
les parametres suivants : 

• identifiant du flot a executer avec le parametre ayant pour cle _f 1 otld. Cet element doit 
etre utilise afin d' identifier le flot a demarrer. 

• cle relative a 1' execution du flot courant avec le parametre ayant pour cle 
_flowExecutionKey ; 

• identifiant de l'evenement declenche avec le parametre ayant pour cle _eventld. 
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Le demarrage d'un flot avec la balise HTML <a href ></a> se realise de la facon suivante : 

<a href="<c:url val ue="/flow/todolists. html ?_flowId 

=flows-todolist"/>">Demarrage du flot f 1 ows-todol i st</a> 

Un appel d'un etat du flot, par le biais de la balise HTML <a href></a>, se realise de la 
maniere suivante : 

<a href ="<c : url val ue="/f 1 ow/todol i sts . html ?_f 1 owExecuti onKey 
=${fl owExecuti onKey}&_eventId=l ist"/>">Mon 1 ien</a> 

Lappel peut egalement etre realise par l'envoi d'un formulaire HTML, qui doit contenir en 
champs caches les deux parametres precedemment cites, comme dans le code suivant : 

<form action="<c:url value="/flow/todolists.html"/>"> 
<input type="hidden" name="_fl owExecuti onKey" 

val ue="<c:out val ue="${f 1 owExecutionKey}"/>"/> 
<input type="hidden" name="_eventld " 

val ue="<c:out val ue="l ist "/>"/> 

(...) 

<input type=" submit" val ue="Envoyer"/> 
</form> 

Spring Web Flow permet egalement de specifier l'evenement au niveau des boutons de 
soumission, comme le montre le code suivant, equivalant au precedent : 

<form action="<c:url value="/flow/todolists.html"/>"> 
<input type="hidden" name="_fl owExecuti onKey" 

val ue="<c:out val ue="${f 1 owExecutionKey}"/>"/> 

(...) 

<input name="_eventld_list" type=" submit" val ue="Envoyer"/> 
</form> 



Configuration de Tudu Lists 

La configuration de 1' application Tudu Lists comporte deux parties : celle du moteur de 
Spring Web Flow et celle des entites utilisees. 

Configuration du moteur de Spring Web Flow 

Puisque nous avons fait le choix d'utiliser le support permettant d'utiliser Spring Web 
Flow avec Spring MVC, le moteur est accessible par l'intermediaire d'un element de 
type Control ler de Spring MVC. 

Toute la configuration du moteur est realisee dans le fichier action-servlet.xml, qui 
correspond a la configuration du contexte de Spring MVC. 

La premiere partie de ce fichier sert a configurer ce Control 1 er, puis son acces (mapping) 
et la strategie de resolution des vues : 

<beans> 

<bean id="messageSource" class="org.springframework. context 
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.support . ResourceBundl eMessageSource"> 
<property name="basename" val ue="messages" /> 
</bean> 

<bean id="exceptionResolver" 

cl ass="tudu.web. Fl owExceptionResol ver" /> 

<bean i d="url Mappi ng" class="org. spring-framework. web 

.servlet. handler. Si mpl eLI rlHandlerMapping"> 
<property name="mappings"> 
<props> 

<prop key="/flow/todolists.html "> 

flowControl 1 er</prop> 
<prop key="/l ogin . html ">loginAction</prop> 
</props> 
</property> 
</bean> 

<bean name=" flowControl 1 er" cl ass="org.springf ramework.webf 1 ow 

. executor. mvc. FlowControl ler"> 

<property name="flowExecutor" ref="flowExecutor"/> 

<property name="cacheSeconds" value="5"/> 
</bean> 

<bean id="viewResolver" class="org.springframework.web 

.servlet. view. Internal ResourceViewResol ver"> 
<property name="viewClass" 

val ue="org.springframework. web. servlet. view. Jstl View" /> 
<property name="pref ix" val ue="/WEB-INF/jsp/" /> 
<property name="suff ix" value=".jsp" /> 



Le controleur s'appuie sur un gestionnaire d'execution de flot correspondant au moteur 
en lui-meme. Ce Bean permet de specifier la strategie de stockage des informations des 
flots ainsi que 1' emplacement des differents fichiers XML de description des flots, 
comme le montre le code suivant, tire du meme fichier action-servlet.xml : 



<bean id="flowExecutor" class="org.springframework 

.webf 1 ow. executor. FlowExecutorlmpl "> 

<constructor-arg> 

<bean id="repositoryFactory" class="org.springframework 
.webf low. execution. repository .continuation 
. Cont i nuati on FlowExecut ion Repository Factory "> 
<constructor-arg ref="f 1 owRegi stry"/> 
</bean> 
</constructor-arg> 
</bean> 



</bean> 



(...) 

</beans> 



<beans> 
(...) 
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<bean id="f 1 owRegi stry" class="org.springframework 

.webflow. registry .Xml Fl owRegi stry Factory Bean "> 
<property name="fl owLocations"> 
<list> 

<value>/WEB-INF/flows-*.xml</value> 
</list> 
</property> 
</bean> 



(...) 

</beans> 

Notons que le sous-flot (Bean d'identifiant flows-todo) doit egalement etre configure en 
tant Bean, meme s'il n'est pas directement rattache au moteur dans la configuration de 
Spring Web Flow. 



Configuration des entites utilisees 

Les differentes actions doivent etre configurees dans le fichier action-servlet.xml, 
correspondant a la configuration du contexte de Spring MVC, afin de les faire beneficier 
de 1' injection de dependances. 

Ce fichier contient la configuration des Beans recapitules au tableau 8.5. 



Tableau 8.5. Actions de Spring Web Flow utilisees dansTudu Lists 



Identifiant 


Classe 




Description 


todoListsAction 


tudu 


web 


TodoListsAction 


Permet de charger la liste des listes de todos d'un utilisateur et de la ren- 
dre disponible par le biais du contexte du flot. Elle utilise des instances 
des classes UserManager et TodoLi stsManager devant etre injectees. 


todoListAction 


tudu 


web 


TodoLi stActi on 


Permet de manipuler une entite de type TodoLi st correspondant a 
une liste de todos. Elle utilise une instance de la classe TodoLi sts- 
Manager devant etre injectee. 


todosAction 


tudu 


web 


TodosAction 


Permet de charger les todos d'une liste de todos et de les rendre dis- 
ponibles par le biais du contexte du flot. Elle utilise une instance de 
la classe TodoLi stsManager devant etre injectee. 


todoAction 


tudu 


web 


TodoAction 


Permet de manipuler une entite de type Todo correspondant a une 
liste de todos. Elle utilise une instance de la classe TodosManager 
devant etre injectee. 



Le code suivant illustre la configuration de ces actions dans le fichier action-servlet.xml : 



<beans> 
(...) 



<bean id=" todoListsAction" class="tudu.web.TodoListsAction"> 
<property name="userManager" ref="userManager"/> 
<property name="todoLi stsManager" ref="todoLi stsManager"/> 

</bean> 
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<bean id="todol_istAction" class="tudu.web.Todol_istAction"> 

<property name="todoLi stsManager" ref="todoLi stsManager"/> 
</bean> 

<bean id="todosAction" class="tudu.web.TodosAction"> 

<property name="todoLi stsManager" ref="todoLi stsManager"/> 
</bean> 

<bean id="todoAction" class="tudu.web.TodoAction"> 

<property name="todosManager" ref="todosManager"/> 
</bean> 

(...) 
</beans> 

Les definitions des Beans de dependances sont localisees dans les fichiers XML dont le 
nom commence par applicationContext, dans le repertoire WEB-INFA 



En resume 

Les elements du flot et entites utilisees, qu'il s'agisse de vues ou de methodes d'actions 
au niveau des etats et des transitions, sont recapitules a la figure 8.7 pour le flot f 1 ow- 
todol 1st decrit dans le fichier flow-todolist.xml du repertoire WEB-INFA 



«view state» 
start 



start.jsp 



todolists 

*| 



«action state » 
todolists 



todoListsAction 
(list) 



«view state » 
show. todolists 



todolists .jsp 



end 



«view state» 
show. end 



end.jsp 



detail 



«action state» 
save .todolist 



todoListAction 
(save) 



todoActionList 
(bindAndValidate) 



« action state» 
todolist 



todoListAction 
(setupForm) 



lisl 



«view state » 
show. todolist 



todolist jsp 



todos 



«view state » 
show. todolist 



todolist jsp 



show.end 



Figure 8.7 

Recapitulatif des elements duflot flow-todolist 
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La figure 8.8 recapitule ces differents elements pour le fiot f 1 ow-todo decrit dans le fichier 
flow-todo.xml du repertoire WEB -INF/. 



«action state» 
todos 



todosAction 
(list) 



«view state» 
show. end 



end.jsp 



«view state» 
show.todos 



todos .jsp 



end 



detail 



«action state» 
todo 



todoAction 
(setupForm) 



detail 



«view state » 
show.todo 



todo.jsp 



«action state» 
save.todo 



todolist jsp 



lisi 



Figure 8.8 

Recapitulatif des elements duflot flow-todo 



Conclusion 

Le framework Spring Web Flow a pour principale fonction d' adresser les problematiques 
liees a la navigation des applications Web. Sa mise en oeuvre n'est toutefois pas appro- 
priee a tous les types d' applications Web. Certaines applications laissent a l'utilisateur le 
loisir de naviguer librement alors que d'autres imposent des regies strides de navigation. 
Spring Web Flow vise a faciliter le developpement de ces dernieres. 

Ce framework decouple et abstrait les differentes briques de mise en ceuvre des Hots 
Web, telles que flot, moteur d'execution de flots et architecture existante (framework 
MVC, par exemple). Cette approche favorise la reutilisation des flots dans differents 
environnements. Le moteur peut egalement etre parametre sans impacter les flots et 
utilise sur differentes architectures. 

Spring Web Flow fournit un cadre robuste et flexible arm de definir un flot, d'implemen- 
ter les actions et les vues, de les relier au flot et d'integrer le flot dans une architecture 
existante par le biais du framework Spring. II reprend d'ailleurs les concepts mis en 
ceuvre dans ce framework ainsi que son implementation MVC. 

Spring Web Flow peut egalement etre utilise avec le support de Spring des portlets. Au 
moment de l'ecriture de cet ouvrage, le framework fournit un exemple experimental 
permettant d'utiliser les flots Web en mode AJAX. Lobjectif affrrme du framework est 
d'etendre le spectre de ces integrations et de devenir par ce biais un standard de fait pour 
la gestion des flots Web. 
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Utilisation d'AJAX 
avec Spring 



Depuis leurs debuts, les applications Web n'offrent a l'utilisateur final qu'une experience 
relative ment pauvre. Le cycle traditionnel requete/reponse sur lequel est fonde le Web ne 
permet pas la creation d' interfaces client elaborees, telles que nous pouvons en observer 
dans les applications bureautiques traditionnelles. 

Le probleme vient essentiellement du fait que chaque action de l'utilisateur requiert un 
rechargement complet de la page HTML. Or c'est sur ce point qu'AJAX intervient en 
permettant le rechargement a chaud de portions d'une page HTML. 

Le terme AJAX (Asynchronous JavaScript And XML) renvoie a un ensemble de techno- 
logies differentes, toutes existantes depuis longtemps mais qui, combinees intelligemment, 
permettent de changer radicalement notre mode de creation des interfaces Web. 

Le concept d'AJAX a ete lance debut 2005 par Jesse James Garrett dans un article devenu 
celebre, intitule AJAX: A New Approach to Web Applications, disponible sur le site Web de 
sa societe, Adaptive Path, a l'adresse http://www.adaptivepath.com/publications/essays/archives/ 
000385.php. 

Les technologies utilisees par AJAX, telles que JavaScript et XML, sont connues depuis 
longtemps, et, en realite, plusieurs societes faisaient deja de 1' AJAX des 2000. La revolu- 
tion actuelle pro vient de l'arrivee a maturite de ces technologies desormais largement 
repandues et livrees en standard avec les navigateurs Internet recents. Pour preuve, des 
entreprises comme Google et Microsoft se mettent a utiliser AJAX de maniere intensive. 
Des produits tels que GMail ou Google Maps sont des exemples de technologies AJAX 
mises a la disposition du grand public. 
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Ce chapitre se penche en detail sur AJAX et introduit plusieurs techniques permettant de 
creer une application en suivant ses principes. Nous aborderons ainsi DWR, l'un des 
frameworks AJAX les plus populaires et qui a la particularite de s'integrer facilement a 
Spring. En particulier, ce framework nous permettra de publier des Beans Spring en 
JavaScript afin de manipuler directement des objets geres par Spring depuis un navigateur 
Internet. 

Nous soulignerons au passage les principaux ecueils qui guettent le developpeur AJAX et 
conclurons le chapitre par une presentation de script.aculo.us, une bibliotheque de scripts 
Open Source qui permet de realiser aisement des effets speciaux. 



AJAX et leWeb 2.0 

Cette section entre dans le detail des technologies et concepts utilises avec AJAX. 

Nous commencerons par demystifier le terme marketing « Web 2.0 », tres souvent asso- 
cie a AJAX. Nous aborderons ensuite le fameux objet XMLHttpRequest, qui est au fondement 
d' AJAX et qui nous permettra de creer une premiere fonction AJAX simple. 



Le Web 2.0 

AJAX est souvent associe au Web 2.0. S'il s'agit la d'une campagne marketing tres bien 
orchestree, force est de reconnaitre que derriere les mots se cache une facon radicalement 
nouvelle de construire des applications Web. 

Le Web 2.0 est un concept plus global qu'AJAX, qui regroupe un ensemble d'aspects 
fonctionnels et metier. L' expression a ete concue par les societes O'Reilly et MediaLive 
International et a ete definie par Tim O'Reilly dans un article disponible a l'adresse http:// 
www. oreillynet. com/lpt/a/6228. 

Nous pouvons retenir de cet article que les applications Web 2.0 s'appuient sur les sept 
principes suivants : 

• Offre d'un service, et non plus d'une application packagee. 

• Controle d'une banque de donnees complexe, difficile a creer et qui s'enrichit au fur et 
a mesure que des personnes l'utilisent. 

• Implication des utilisateurs dans le developpement de 1' application. 

• Utilisation de 1' intelligence collective, les choix et les preferences des utilisateurs etant 
utilises en temps reel pour ameliorer la pertinence du site. 

• Choix de laisser les internautes utiliser 1' application comme un self-service, sans 
contact humain necessaire. 

• Fonctionnement de 1' application sur un grand nombre de plates-formes, et plus seule- 
ment sur l'ordinateur de type PC (il y a aujourd'hui plus de terminaux mobiles que de 
PC ayant acces a Internet). 
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• Simplicity des interfaces graphiques, des processus de developpement et du modele 
commercial. 

Nous comprendrons mieux cette philosophie en observant des sites emblematiques de ce 
Web 2.0, tels que les suivants : 

• Wikipedia, une encyclopedie en ligne geree par les utilisateurs eux-memes. Chacun est 
libre d'y ajouter ou de modifier du contenu librement, des groupes de benevoles se 
chargeant de relire les articles afin d'eviter les abus. 

• Les blogs, qui permettent a chacun de participer et de lier (mecanisme des trackbacks) 
des articles. 

• del.icio.us et Flickr, des sites collaboratifs dans lesquels les utilisateurs gerent leurs 
donnees en commun (des liens pour del.icio.us, des images pour Flickr). Ainsi, chacun 
participe a l'enrichissement d'une base de donnees geante. 

Le Web 2.0 est done davantage un modele de fonctionnement collaboratif qu'une techno- 
logie particuliere. Pour favoriser l'interactivite entre les utilisateurs, ces sites ont besoin 
d'une interface graphique riche et dynamique. C'est ce que leur propose AJAX, avec sa 
capacite a recharger a chaud des petits morceaux de pages Web. Ces mini-mises a jour 
permettent a l'utilisateur d'enrichir la base de donnees de 1' application sans pour autant 
avoir a recharger une page HTML entiere. 

Tudu Lists, notre application etude de cas, est un modeste representant du Web 2.0, 
puisqu'elle permet le partage de listes de taches entre utilisateurs, a la fois en mode Web 
(avec AJAX) et sous forme de flux RSS. 

Les technologies d'AJAX 

AJAX met en oeuvre un ensemble de technologies relativement anciennes, que vous avez 
probablement deja rencontrees. 

Un traitement AJAX se deroule de la maniere suivante : 

1. Dans une page Web, un evenement JavaScript se produit : un utilisateur a clique sur 
un bouton (evenement onCl i ck), a modifie une liste deroulante (evenement onChange), 
etc. 

2. Le JavaScript qui s'execute alors utilise un objet particulier, le XMLHttpRequest ou, si 
vous utilisez Microsoft Internet Explorer, le composant ActiveX Microsoft.XMLHTTP. 
Cet objet n'est pas encore standardise, mais il est disponible sur 1' ensemble des navi- 
gate urs Internet recents. Situe au cceur de la technique AJAX, il permet d' envoy er une 
requete au serveur en tache de fond, sans avoir a recharger la page. 

3. Le resultat de la requete peut ensuite etre traite en JavaScript, de la me me maniere 
que lorsque nous modifions des morceaux de page Web en DHTML. Ce resultat est 
generalement du contenu renvoye sous forme de XML ou de HTML, que nous 
pouvons ensuite afheher dans la page en cours. 
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AJAX est done un melange de JavaScript et de DHTML, des technologies utilisees 
depuis bien longtemps. L'astuce vient essentiellement de ce nouvel objet XMLHttpRequest, 
lui aussi present depuis longtemps, mais jusqu'a present ignore du fait qu'il n'etait pas 
disponible sur suffisamment de navigateurs Internet. 

Voici un exemple complet de JavaScript utilisant cet objet XMLHttpRequest pour faire un 
appel de type AJAX a un serveur. C'est de cette maniere que fonctionnaient les anciennes 
versions de Tudu Lists (avant l'arrivee de DWR, que nous detaillons plus loin dans ce 
chapitre). Cet exemple illustre le reaffichage a chaud d'une liste de taches, ainsi que 
1' edition d'une tache : 

<script language="JavaScript"> 

var req; 

var fragment; 

/** 

* Fonction AJAX generique pour utiliser XMLHttpRequest. 
*/ 

function retrieveURL(url ) { 
if (window. XMLHttpRequest) { 
req = new XMLHttpRequest( ) ; 
req.onreadystatechange = miseAJourFragment; 
try { 

req.openC'GET", url, true); 
} catch (e) { 
al ert( "<fmt: mess age key="todos.ajax.error"/>" ) ; 

} 

req.send(null ); 
} // Utilisation d'ActiveX, pour Internet Explorer 
else if (window. ActiveXObject) { 

req = new ActiveXObjectt "Microsoft .XMLHTTP" ) ; 

if (req) { 

req.onreadystatechange = miseAJourFragment; 
req.openC'GET", url, true); 
req.send( ) ; 

} 

} 

} 

/** 

* Met a jour un fragment de page HTML. 
*/ 

function miseAJourFragment( ) { 
if (req.readyState == 4) { // requete completee 
if (req. status == 200) { // reponse OK 

document .get El ement By Id (fragment) 
.innerHTML = req.responseText; 

} else { 
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alert("<fmt:message key="todos.ajax.error"/> " + 
req. status) ; 

} 

} 

} 

/** 

* Affiche la liste des taches. 

*/ 

function afficheLesTaches( ) { 
fragment='todosTable' ; 

retrieveURK ' ${ctx} /a jax/manageTodos. action? ' + 
'1 istId=${todoList. 1 istId}&method=render ' ) ; 

} 

/** 

* Edite une tache. 
*/ 

function editeUneTache(id) { 
f ragment='editFragment' ; 

retrieveURK '${ctx}/ajax/manageTodos.action?todoId=' + 
escape(id) + '&method=edit' ) ; 

} 

( ... ) 

</script> 

Dans cet exemple, des fragments de page sont mis a jour a chaud, avec du contenu 
HTML renvoye par le serveur. 

Comme nous pouvons le deviner en regardant les URL envoyees au serveur, ces requetes 
HTTP sont traitees par des actions Struts, le parametre method etant utilise par des actions 
Struts de type DispatchAction (voir le chapitre 6 pour plus d' informations sur le traitement 
de ces requetes ). 

Le HTML renvoye par les actions Struts est simplement affiche dans des elements 
HTML. En l'occurrence, la methode innerHTML utilisee plus haut permet de changer le 
HTML present dans des elements <span> : 

<span id= "edit Fragment "></span> 

<span id="todosTable"X/span> 

Cette utilisation d'AJAX reste tres simple mais reclame une relativement bonne connais- 
sance de JavaScript. Suffisante pour un site Web simple, elle souffre cependant des quelques 
lacunes suivantes : 

• Elle necessite beaucoup de code JavaScript et devient difficile a utiliser des lors que 
nous voulons faire plus que simplement afficher du HTML. 

• Elle pose des problemes de compatibility d'un navigateur a un autre. 
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Afin de faciliter 1' utilisation de ce type de technique, un certain nombre de frameworks 
ont vu le jour, tels Dojo, DWR, JSON-RPC, MochiKit, SAJAX, etc. 

Nous presentons DWR, l'un des plus populaires, dans la suite de ce chapitre. 

Le framework AJAX DWR (Direct Web Remoting) 

Parmi la multitude de frameworks AJAX, nous avons choisi DWR pour sa popularite et 
son integration a Spring. DWR permet tres facilement de presenter en JavaScript des 
JavaBeans geres par Spring. II est ainsi possible de manipuler dans un navigateur Internet 
des objets s'executant cote serveur. 

DWR est un framework Open Source developpe par Joe Walker, qui permet d'utiliser 
aisement des objets Java (cote serveur) en JavaScript (cote client). 

Fonctionnant comme une couche de transport, DWR permet a des objets Java d'etre utili- 
ses a distance selon un principe proche du RMI (Remote Method Invocation). Certains 
autres frameworks AJAX, comme Rico, proposent des bibliotheques beaucoup plus 
completes, avec des effets speciaux souvent tres impressionnants. Pour ce type de resul- 
tat, DWR peut etre utilise conjointement avec des bibliotheques JavaScript non specifiques 
a J2EE. Nous abordons plus loin dans ce chapitre l'utilisation conjointe de DWR et de 
script. aculo. us, une bibliotheque d' effets speciaux tres populaire parmi les utilisateurs 
de Ruby On Rails. 

Signe de la reconnaissance de DWR par la communaute Java, des articles ont ete publies 
sur les sites developpeur de Sun, IBM et BEA. Dans le foisonnement actuel de 
frameworks AJAX, nous pouvons raisonnablement avancer que DWR est l'un des plus 
prometteurs. 

Publie sous licence Apache 2.0, ce framework peut etre utilise sans probleme, quelle que 
soit P application que vous developpez. 

Principes de fonctionnement 

DWR est compose de deux parties : du JavaScript, qui s'execute cote client dans le navi- 
gateur de l'utilisateur, et une servlet Java, laquelle est chargee de traiter les requetes 
envoyees par le JavaScript. 

DWR permet de presenter des objets Java en JavaScript et de generer dynamiquement le 
JavaScript necessaire a cette fonctionnalite. Les developpeurs JavaScript ont ainsi la 
possibilite d'utiliser de maniere transparente des objets Java, qui tournent dans le serveur 
d' applications et qui done ont la possibilite d'acceder a une base de donnees, par exem- 
ple. Cela augmente considerablement les possibilites offertes a l'interface graphique 
d'une application. 

La figure 9.1 illustre l'appel d'une fonction Java depuis une fonction JavaScript contenue 
dans une page Web. 
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Navigateur Internet 

HTMLVJavaScript 

/WEB-INF/jsp/todosjsp 



function showEditTodo(todold) { 
todos.getTodoByld(reply, todold); 



var reply = function(todo) { 
document.forms 
editTodoFormdescription .value =_ 
todcdescription; 

} 




Figure 9.1 

Fonctionnement de DWR 



DWR 



Serveur J2EE 

Java 

tuduweb.dwr.impl.TodosDwrlrnpl 



public Todo getTodoByld(String 
todold) { 

Todo todo = 
todosManager.findTodo(todold); 
return todo; 



Afin de mieux illustrer ce propos, voici comment fonctionne une version simplified du 
code permettant d'editer une tache a chaud dans Tudu Lists. 

Suite au clic de souris d'un utilisateur sur le texte « edit », a droite d'une tache, le Java- 
Script suivant s' execute : 

function showEditTodo(todoId) { 
Effect. Appeart 'editTodoDiv' ) ; 
todos.getTodoByldtreply, todold) ; 
document .forms .editTodo Form. description .focus ( ) ; 

} 

Ce code affiche le layer DHTML d'edition d'une page (il s'agit d'un effet special de 
script.aculo.us), appelle un objet Java distant et donne le focus a la description de la tache 
editee. 

Le code d'appel a la fonction Java est compose d'un objet todo, genere automatiquement 
par DWR, qui prend les deux parametres suivants en fonction : 

• reply, la fonction callback JavaScript. II s'agit done non pas d'une variable passee en 
argument, mais d'une fonction JavaScript qui s'execute apres l'execution de l'appel a 
P objet Java. 

• todold, Pidentifiant de la tache a editer, qui est passe en argument a la fonction Java 
distante. 
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Ce code appelle la fonction Java distante getTodoByld de l'objet todo presents par DWR : 
package tudu.web.dwr.impl ; 

( ... ) 

/** 

* Implementation du service tudu. service. TodosManager. 

*/ 

public class TodosDwrlmpl implements TodosDwr { 
( ... ) 

public RemoteTodo getTodoById(String todold) ( 
Todo todo = todosManager.findTodo(todoId) ; 
RemoteTodo remoteTodo = new RemoteTodo ( ) ; 
remoteTodo.setDescription(todo.getDescription( ) ) ; 
remoteTodo. setPriority(todo.getPriority( )) ; 
if (todo.getDueDate( ) != null) { 
Simpl eDateFormat formatter = 
new SimpleDateFormat( "MM/dd/yyyy" ) ; 

String formattedDate = formatter. format(todo. getDueDate( )) ; 
remoteTodo. setDueDate(formattedDate) ; 
} else { 
remoteTodo. setDueDate ( " " ) ; 

} 

return remoteTodo; 

} 

} 

Ce code Java recherche la tache demandee dans la couche de service de 1' application, 
laquelle fait a son tour un appel a la couche de persistance afin qu'Hibernate retrouve les 
informations en base de donnees. Pour des raisons de securite, que nous verrons plus tard 
dans ce chapitre, ce code cree un objet Java specifique pour la couche DWR, et cet objet 
est retourne au client. 

Au retour d'execution du code Java, la fonction callback reply, que nous avons vue plus 
haut, s' execute : 

var reply = function(todo) { 

document. forms.editTodoForm. description. value = todo. description; 
document. forms. editTodoForm. priority. value = todo. priority ; 
document. forms. editTodoForm.dueDate. value = todo.dueDate; 

} 

Etant une fonction callback, elle prend automatiquement un seul argument, l'objet 
retourne par la fonction JavaScript getTodoByld. Cela revient a dire qu'elle utilise 
l'objet Java retourne par la methode getTodoByld, qui represente une tache. II est ensuite 
aise de recopier les attributs de cet objet dans les champs HTML du layer presentant la 
tache ainsi editee. 
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Configuration 

Vu de l'exterieur, DWR se compose d'une servlet et d'un fichier de configuration, 
nomme dwr.xml. Sa configuration n'est done pas particulierement complexe, d'autant 
que le framework fournit une excellente interface de test. 

La servlet DWR 

DWR est tout d'abord une servlet, qu'il faut configurer dans l'application Web en cours. 
Les differents JAR fournis dans la distribution de DWR doivent done etre copies dans le 
repertoire WEB-INF/lib, et la servlet DWR doit etre configuree dans le fichier WEB- 
INF/web.xml, comme toutes les servlets : 

( ... ) 
<servlet> 

<servl et-name>dwr-invoker</servl et-name> 

<servl et-cl ass>uk. 1 td.getahead .dwr. DWRServl et</servlet-cl ass> 
<init-param> 

<param-name>debug</param-naiTie> 

<param-val ue>fal se</param-val ue> 
</init-param> 
</servlet> 

( ... ) 

<servlet-mapping> 

<servl et-name>dwr-invoker</servlet-name> 

<url -pattern>/secure/dwr/*</url -pattern> 
</servlet-mapping> 
(...) 

Dans cette configuration, le parametre debug peut etre mis a true afin d'avoir des informa- 
tions plus precises sur le fonctionnement de DWR. Par ailleurs, l'URL d'acces a DWR 
est /secure/dwr/*. Cette URL est bien entendu librement configurable. Dans Tudu Lists, 
nous preferons la mettre derriere l'URL /secure/*, afin qu'elle soit protegee par Acegi 
Security. 

Le fichier dwr.xml 

DWR est configure via un fichier, qui est par defaut WEB-INF/dwr.xml. Ce fichier est 
configurable grace aux parametres d'initialisation de la servlet DWR : 

<servlet> 

<servl et-name>dwr-user-invoker</servl et-name> 

<servl et-cl as s>uk.l td.getahead. dwr. DWRServl et</servl et-cl ass> 

<init-param> 

<param-naine>conf ig-user</param-naine> 

<param-val ue>WEB-INF/dwr-user.xml </param-val ue> 
</init-param> 
</servlet> 
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Le nom du parametre doit imperativement commencer par config. C'est pourquoi, dans 
l'exemple ci-dessus, nous l'avons appele config-user. Linteret de cette manipulation est 
d'autoriser plusieurs fichiers de configuration, et ainsi plusieurs instances differentes de 
la servlet DWR : une instance pour les utilisateurs normaux (conf i g-user) et une pour les 
administrateurs (conf i g-admi n). En leur donnant des URL differentes, nous pouvons utili- 
ser la securite standard de J2EE pour ne permettre qu'aux utilisateurs ayant un role 
donne d'utiliser une instance de DWR. 

Le fichier dwr.xml est de la forme suivante : 

<dwr> 
<init> 

<creator id="..." class="..."/> 
<converter id="..." cl ass=" . . . "/> 
</init> 

<allow> 

<create creator^" . . . " javascript=" . . . " scope="..."> 

<param name="..." val ue=" . . . "/> 
</create> 

<convert convertor=" . . . " match="..."/> 
</allow> 

<signatures> 

( ... ) 
</signatures> 
</dwr> 

La partie <init></init> n'est generalement pas utilisee. Elle sert a instancier les classes 
utilisees plus bas dans le fichier de configuration, dans le cas oil le developpeur souhaite- 
rait utiliser ses propres classes au lieu de celles fournies en standard par DWR. Nous 
allons voir que les classes livrees avec DWR sont cependant largement suffisantes pour 
une utilisation de l'outil, fut-elle avancee. 

La section <al 1 owX/al 1 ow> indique a DWR quelles classes il a le droit d'instancier et de 
convertir. Cette section est la plus importante du fichier. Nous allons detailler les 
elements Creator et Convertor qui la composent. 

Pour instancier une classe, DWR utilise un Creator, defini dans le fichier de configuration 
par la balise <create>. Ce Creator peut instancier une classe de plusieurs manieres et les 
associer a un JavaScript genere a la volee : 

<al 1 ow> 

<create creator="new" javascript="Example"> 

<param name="cl ass" value="tudu.web.dwr.Example"/> 
</create> 
</allow> 

Dans cet exemple, le Creator new permet d'instancier une classe et de l'associer a un 
JavaScript nomme Example. II s'agit du Creator le plus simple, mais il en existe d'autres, 
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en particulier pour acceder a des Beans Spring, ce que nous verrons dans l'etude de cas. 
L'objet Example une fois presente ainsi en JavaScript, ses methodes peuvent etre appelees 
depuis le navigateur client. Cependant, il est tout a fait possible que lesdites methodes 
utilisent comme arguments, ou comme objets de retour, des classes complexes, telles que 
des collections ou des JavaBeans. Ces classes vont done devoir etre converties d'un 
langage a 1' autre. 

Pour convertir une classe Java en JavaScript et vice versa, DWR utilise des Converters. 
En standard, DWR est fourni avec des Converters permettant la conversion des types Java 
primaires, des dates, des collections et des tableaux, des JavaBeans, mais aussi d'objets 
plus complexes, comme des objets DOM ou Hibernate. 

Pour des raisons de securite, certains Converters complexes, comme celui gerant les 
JavaBeans, ne sont pas actives par defaut. Pour convertir un JavaBean en JavaScript, il 
faut done autoriser sa conversion : 

<allow> 
<convert converter="bean" 

match= "tudu. web. dwr. bean. RemoteTodo List" /> 

<convert converter="bean" 

match=" tudu. web. dwr .bean. RemoteTodo "/> 

</allow> 

Utilisation du JavaScript dans les JSP 

Une fois la servlet DWR correctement configuree, il est necessaire d'acceder au code 
JavaScript genere dynamiquement par le framework depuis les pages JSP. Pour cela, il 
faut importer dans les JSP les deux bibliotheques propres a DWR : 

<script type="text/javascript" 

src="$(ctx}/secure/dwr/engine. js"X/script> 

<script type=" text/ javascript" 

src="$(ctx}/secure/dwr/uti 1 . js"X/script> 

Dans Tudu Lists, cet import est realise dans le fichier WEB-INF/jspf/header.jsp. 

Notons que ces deux fichiers JavaScript sont fournis par la servlet DWR et qu'ils n'ont 
pas a etre ajoutes manuellement dans 1' application Web. 

II faut ensuite importer les fichiers JavaScript generes dynamiquement par DWR et qui 
representent les classes Java decrites dans dwr.xml. Voici l'exemple de la classe 
tudu. web. dwr. impl .TodosDwrlmpl , qui est configuree dans dwr.xml pour etre presentee en 
tant que todos : 

<script type='text/javascript' 

src='$(ctx}/secure/dwr/interface/todos. js'X/script> 

Ce fichier doit done etre importe depuis la servlet DWR mappee dans Tudu Lists sur 
l'URL /secure/dwr/*, a laquelle nous ajoutons le suffixe interface. 
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Test de la configuration 

La configuration etudiee ci-dessus est relativement complexe, l'import et l'utilisation du 
JavaScript genere posant generalement probleme aux nouveaux utilisateurs. C'est pourquoi 
DWR est fourni avec une interface de tests tres bien concue. Pour la mettre en place, il faut 
modifier la configuration de DWR dans le fichier web.xml, afin de passer en mode debug : 

<servlet> 

<servl et-name>dwr-invoker</servl et-name> 

<servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class> 
<init-param> 

<param-name>debug</param-name> 

<param-val ue>true</param-val ue> 
</init-param> 
</servlet> 

Notons bien que cette configuration ne doit pas etre utilisee en production, car elle facili- 
terait la tache d'une personne malveillante. 

Une fois ce parametrage effectue, nous pouvons acceder a des pages de test via l'URL de 
la servlet DWR, qui, dans notre etude de cas, est http://1 27.0.0.1 :8080/Tudu/secure/dwr/ (si vous 
avez change la racine de contexte du projet, remplacez Tudu dans l'URL par la nouvelle 
racine, en respectant les majuscules). Ces pages listent les objets presentes par DWR, 
ainsi que leurs methodes. Ces methodes peuvent etre appelees directement. Le code 
source de ces pages fournit une aide precieuse pour l'utilisation de DWR. 

La figure 9.2 illustre la page affichant la classe TodosDWRImpl , l'une des deux classes confi- 
gurers avec DWR dans Tudu Lists. 



Figure 9.2 



Interface de test de DWR /\ J_g »hro://i27.o.o.i:8080/t, t o W 



Methods For: todos (tudu.web.dwr.impl.TodosDwrlmpl) 

To use this class in your javascript you will need die following script includes: 

eaeript type- text/ javaaeript arc-' /tadu/3ccuro/dwr/intorlacc/todofl.Tfl 's*/ecript>| 
'eonpt type toxt / )avaeeript ' arc- ' / tudu/aoouro/dwr/onqino .-io >*/ecriDt* 

In addition there is an optional utility script: 

<aeript type- ' text / javaaeript ' arc-' /tudu/accurc/dwr/util. io 'x/acript> 

Replies Irom UW'K arc shown with a yellow background il they arc simple or in an alert box otherwise. 
The inputs arc evaluated as Javascript so strings must be quoted before execution. 

There arc 21 declared methods: 

• sctUscrManagcr< ); e»«»«| 

(Warning- NnCnnve-rtfrrnriudu vrvir* llvrManagfr See hHnwi 

• scfTodnl .isrsManagcrf ); tt*r„»\ 

(Warning: No Converter for tudu .Krvice.TodoLittiManaecr. Sec below) 

• delete 1 odo( ™ ): 

• complete Todo( "" I: ! ■ , 

• reopen I odo( " ): t.v.m. I 

• sctlodosManagcrt 1: 

(Warning: No Converter lor tudu -sarvice.TodosManager. Sec below ) 

• gctCurnentTodoI.iitsf ), iwum | 

• gctTr«lonyId( "" ); ...q... | 
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Utilisation de I' API servlet 

DWR permet de s'abstraire de l'API servlet, ce qui simplifie generalement grandement le 
travail a effectuer. En comparaison de Struts, nous utilisons directement des arguments 
passes en parametres au lieu de les extraire depuis un objet de formulaire. 

L'API servlet reste toutefois incontournable pour peu que nous voulions stacker des attri- 
buts dans la session HTTP, utiliser JAAS pour la securite ou acceder au contexte de 
l'application Web. Pour toutes ces utilisations, DWR stocke dans une variable Thread- 
Local les objets HttpServletRequest, HttpServl etResponse, HttpSession, Servl etContext et 
ServletConfig. 

Pour acceder a la requete HTTP en cours, il suffit d'ecrire : 

HttpServletRequest request 
= uk.l td.geta head. dwr.WebContext Factory. get ( ) 
.getHttpServl et Request ( ) ; 

L'acces a cette variable en ThreadLocal n'est bien entendu possible que pour les fils 
d' execution correspondant a des requetes traitees avec DWR. 



Gestion des performances 

A premiere vue, l'utilisation d'AJAX ameliore les performances. Au lieu de demander 
au serveur de recharger des pages completes, nous nous contentons de lui demander le 
strict minium. 

Cependant, des que nous maitrisons cette technique, nous sommes rapidement pousses a 
multiplier les requetes cote serveur. Le site devient alors plus riche, plus « Web 2.0 », 
mais, en contrepartie, les requetes HTTP se trouvent multipliees. 

Cout de DWR en matiere de performances 

En lui-meme, DWR n'ajoute qu'un impact negligeable en matiere de performances cote 
serveur. Le serveur d'applications, le temps reseau ou les traitements metier sont norma- 
lement bien plus importants. 

Joe Walker, l'auteur de DWR, a effectue plusieurs tests qui lui permettent de proposer les 
optimisations suivantes : 

• Les appels de moins de 1 500 octets peuvent tenir dans un seul paquet TCP, ce qui 
ameliore sensiblement l'utilisation du reseau. II est done important de n'echanger que 
le strict minimum de donnees. 

• L'utilisation de parametres de la JVM privilegiant les objets a faible duree de vie 
apporte un gain de performances, tout du moins avec Tomcat. Avec une JVM Sun, il 
s'agit de l'option -XX:NewSize. 
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Utilisation de batchs pour les requetes 

II est possible de grouper des requetes DWR afln de diminuer le nombre d'allers-retours 
entre le client et le serveur. Nous retrouvons cette optimisation a plusieurs endroits dans 
Tudu Lists, en particulier lors de l'ajout d'un todo : 

DWREngine.beginBatch( ) ; 
todos . addTodo( reply RenderTable, 
listld, description, priority, dueDate); 

todos .getCurrentTodo Li sts ( replyCurrentTodoLi sts ) ; 
DWREngine.endBatch( ) ; 

La fonction beginBatch( ) permet de placer les requetes suivantes en queue et de ne les 
envoyer qu'une fois la methode endBatch( ) executee. 

Etude des performances avec JAMon 

Ann de mieux etudier les performances des appels a DWR, nous avons utilise JAMon, un 
outil Open Source de monitoring des performances disponible a l'adresse http://www.jamo- 
napi.com/. 

Pour cela, nous avons cree un filtre de servlet, disponible dans Tudu Lists mais que vous 
pouvez reutiliser sans modification dans votre propre application. Cette classe, 
tudu. web. filter. JAMonFi 1 ter, permet d'accumuler des statistiques sur l'ensemble des 
requetes HTTP envoyees au serveur. Ces statistiques sont ensuite visualisables via 
JAMonAdmin.jsp, une JSP fournie sur le site de JAMon et que nous avons integree dans 
Tudu Lists. II s'agit de l'onglet Monitoring, qui est uniquement accessible aux adminis- 
trateurs de 1' application. 

Grace a ce filtre et a la JSP permettant d'etudier les statistiques, il est possible de trouver 
les requetes AJAX qui prennent le plus de temps ou celles qui sont appelees le plus 
souvent. 

Dans le cas particulier de Tudu Lists, la requete la plus utilisee en production est l'appel 
a la methode renderTodos du Bean Spring todosDwr. Elle est appelee plusieurs dizaines de 
milliers de fois par jour et a un temps de reponse inferieur a 10 millisecondes. 



Integration de Spring et de DWR 

DWR propose une ingenieuse integration a Spring, qui permet d'utiliser directement des 
Beans Spring en JavaScript. 

II faut pour cela utiliser un Creator particulier, nomme spring, qui indique a DWR que le 
Bean en question est gere par Spring. Ce createur prend en parametre 1TD du Bean 
Spring. C'est cette configuration que nous retrouvons dans Tudu Lists : 

<dwr> 
<allow> 
<create creator="spring" 
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javascript="todo_l i sts" scope="appl ication"> 

<param name="beanName" val ue="todoLi stsDwr" /> 
</create> 

<create creator="spring" 

javascript="todos" scope="appl ication"> 

<param name="beanName" val ue="todosDwr" /> 
</create> 

( ... ) 

</allow> 
</dwr> 

Dans cet exemple, nous publions en JavaScript les Beans Spring nommes todoLi stsDwr et 
todosDwr, par 1' intermediate de DWR. Ces Beans ont bien entendu ete configures au 
prealable dans un contexte Spring, nomme WEB-INF/applicationContext-dwr.xml. 

Voici la configuration du premier Bean, todoLi stsDwr : 

<bean id="todoListsDwr" 

class="tudu.web.dwr.impl .TodoListsDwrlmpl "> 

<property name= " todoLi stsManager"> 
<ref bean="todoListsManager" /> 
</property> 

<property name="userManager"> 
<ref bean="userManager" /> 
</property> 
</bean> 

Les Beans Spring ainsi configures sont accessibles en JavaScript. En voici un exemple 
d' utilisation, tire de la page JSP WEB-INF/jsp/todo_lists.jsp, qui sert a gerer les listes 
de taches : 

<script type='text/javascript' 

src=' $(ctx}/secure/dwr/interface/todo_l i sts . js '> 
</script> 

<script type="text/javascript"> 
( ... ) 

// Ajout d'un utilisateur a la liste sel ectionnee. 
function addTodoLi stUsert ) { 

var listld = document. forms. editListForm.listld. value; 

var login = document. forms. editListForm. login. value; 

todo_l i sts .addTodoLi stUser( replyAddTodoListUser , listld, 1 ogin) ; 

} 
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Tudu Lists : utilisation d'AJAX 

Nous utilisons la technologie AJAX dans les deux pages principales de 1' etude de cas 
Tudu Lists, la page de gestion des listes de todos et la page de gestion des todos. 

Tudu Lists utilise DWR, integre a Spring de la maniere etudiee precedemment, afin 
d'editer, ajouter, supprimer ou afficher des entites gerees dans la couche de service de 
1' application et persistees avec Hibernate. 

Fichiers de configuration 

Les fichiers de configuration sont ceux etudies precedemment : 

• WEB-INF/web.xml, qui sert a configurer la servlet DWR.xml. 

• WEB-INF/applicationContext-dwr.xml, qui gere les Beans Spring presentes avec 
DWR. 

• WEB-INF/dwr.xml, qui est le fichier de configuration de DWR. 

Chargement a chaud d'un fragment de JSP 

Nous allons commencer par l'exemple le plus simple, le chargement a chaud d'un frag- 
ment HTML genere cote serveur par une JSR L'utilisation d'AJAX ne necessite pas 
obligatoirement l'utilisation et la transformation de donnees en XML. II est possible de 
generer une chaine de caracteres cote serveur et de 1' afficher directement dans la page HTML 
en cours. Dans le monde J2EE, le moyen naturel pour generer du HTML etant un fichier 
JSR voici de quelle maniere transferer une JSP en AJAX. 

Cette technique s' applique aux deux fichiers WEB-INF/jspf7todo_lists_table.jsp et 
WEB-INF/jspf/todos_table.jsp. Nous allons etudier plus precisement ce deuxieme 
fichier, qui est essentiel a la generation de la principale page de 1' application. Voyons 
pour cela le JavaScript contenu dans la page WEB-INF/jsp/todos.jsp qui va utiliser ce 
fragment de JSP : 

function renderTabl e( ) { 
var listld = document. forms. todoForm.listld. value; 
todos . renderTodos (reply RenderTabl e, listld); 

} 

var replyRenderTabl e = function(data) { 
DWRUtil .setValue( 'todosTable' , 
DWRUtil .toDescriptiveString(data, 1) ) ; 

} 

La fonction renderTable( ) utilise l'objet todos, qui est un Bean Spring presente par 
DWR, pour generer du HTML. La variable replyRenderTabl e est une fonction callback 
prenant automatiquement en parametre l'argument de retour de la fonction renderTodos. 
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Elle utilise des mefhodes utilitaires fournies par DWR pour afficher cet argument de 
retour dans l'entite HTML possedant l'identifiant todosTable. 

Ces fonctions utilitaires, fournies par le fichier util.js, ont ete importees via le header de 
la JSP WEB-INF/jspf/header.jsp. Ce ne sont pas des fonctions AJAX, et elles ne servent 
qu'a faciliter l'affichage sans etre pour autant obligatoires. Les deux fonctions utilisees 
ici sont les suivantes : 

• DWRUtil .setValue(id, value), qui recherche un element HTML possedant l'identifiant 
donne en premier argument et lui donne la valeur du second argument. 

• DWRUtil .toDescriptiveString(objet, debug), une amelioration de la fonction toString 
qui prend en parametre un niveau de debug pour plus de precision. 

La partie la plus importante du code precedent concerne la fonction todos . renderTodos ( ), 
qui prend en parametre la fonction callback que nous venons d'etudier ainsi qu'un iden- 
tifiant de liste de todos. 

Comme nous pouvons le voir dans le fichier WEB-INF/dwr.xml, cette fonction est en 
fait le Bean Spring todosDwr : 

<create creator="spring" javascript="todos" scope="appl ication"> 

<param name="beanName" val ue="todosDwr" /> 
</create> 

Ce JavaBean est lui-meme configure dans WEB-INF/applicationContext-dwr.xml : 

<bean id="todosDwr" class="tudu.web.dwr.impl .TodosDwrlmpl "> 

La fonction appelee est au final la fonction renderTodostString listld) de la classe 
TodosDwrlmpl . 

Cette methode utilise la methode suivante pour retourner le contenu d'une JSP : 

return WebContextFactory .get( ) .forwardToString( 

VWEB-INF/jspf/todos_table. jsp") ; 

Cette methode permet done de recevoir le resultat de l'execution d'une JSP sous forme 
de chaine de caracteres, que nous pouvons ensuite inserer dans un element HTML de la 
page grace a la fonction DWRUti 1 . setVal ue( ), que nous avons vue precedemment. 

Cette technique evite d'utiliser du XML, qu'il faudrait parser et transformer cote client. 
Elle permet d'utiliser un resultat qui a en fait ete obtenu cote serveur. En ce sens, ce n'est 
done pas une technique AJAX « pure ». Elle a cependant l'avantage d'etre simple et 
pratique. 



Modification d'un tableau HTML avec DWR 

Dans l'etape suivante de notre etude de cas, nous utilisons plus completement l'API de 
DWR en modifiant les lignes d'un tableau HTML. Cette technique permet de creer 
des tableaux editables a chaud par l'utilisateur. Ce dernier peut en changer les lignes 
et les cellules sans pour autant avoir a subir le rechargement de la page Web en cours. 
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La page utilisee pour gerer les todos, WEB-INF/jsp/todos.jsp, possede un menu sur la 
gauche, qui contient un tableau contenant les listes de todos possedees par l'utilisateur. 
Ce tableau est gere en AJAX grace au JavaScript suivant : 

function renderMenut ) { 
todos .getCurrentTodo Lists ( replyCurrentTodoLists) ; 

} 



var replyCurrentTodoLists = function(data) { 
DWRUti 1 . removeAl 1 Rows( "todoListsMenuBody" ) ; 
DWRUtil .addRowsC'todoListsMenuBody", data, 
[ selectTodoListLink ]); 

} 



function selectTodoListLink(data) { 

return "<a href=\"javascript:renderTableListId( '" 
+ data.listld + "')\">" + data. description + "</a>"; 

} 

Nous utilisons les deux elements importants suivants : 

• renderMenu( ), qui est la fonction appelee a d'autres endroits de l'application pour 
generer le tableau. En 1' occurrence, cette fonction est appelee au chargement de la 
page, lors de la mise a jour des todos, ainsi que par une fonction lui demandant un 
rafraichissement toutes les deux minutes. En effet, les listes de todos pouvant etre 
partagees avec d'autres utilisateurs, les donnees doivent etre regulierement rafraichies. 
Cette fonction appelle un Bean Spring presente avec DWR, dont nous connaissons 
maintenant bien le fonctionnement, et utilise une variable callback. 

• replyCurrentTodoLists, qui est une fonction callback prenant comme parametre le 
resultat de la methode todos. getCurrentTodoListsO. Cette methode, qui appartient a la 
classe tudu.web.dwr.impl . Todos Dwr Impl , retourne un tableau de JavaBeans, de type 
tudu.web.dwr.bean.RemoteTodoList. Afin de retourner un tableau de listes de todos, nous 
n'utilisons pas directement le JavaBean tudu. domain. model .TodoList. Presenter en Java- 
Script un objet de la couche de domaine pourrait en effet presenter un risque en matiere 
de securite. Pour cette raison, seuls des Beans specifiques a la presentation sont autorises 
dans DWR, via la section <al 1 owX/al 1 ow> du fichier WEB-INF/dwr.xml. 

Cette derniere fonction fait appel aux classes utilitaires de DWR suivantes, qui permettent 
de gerer les elements de tableau : 

• DWRUtil . removeAl lRows(id), qui enleve toutes les lignes du tableau HTML possedant 
l'identifiant passe en argument. 

• DWRUtil .addRows( id, data, eel 1 Funcs ), qui ajoute des lignes au tableau HTML posse- 
dant 1'identifiant passe en premier argument. Les donnees utilisees pour construire ce 
tableau sont passees dans le deuxieme parametre de la fonction et sont un tableau 
d'objets. Le troisieme parametre est un tableau de fonctions. Chacune de ces fonctions 
prend en parametre un element du tableau, ce qui permet de creer les cellules. 
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Dans notre exemple, le tableau n'ayant qu'une colonne, une seule fonction, selectTodo- 
ListLink(data), prend done en parametre un JavaBean, tudu. web. dwr. bean. RemoteTodoList, 
converti au prealable en JavaScript. 

Nous pouvons ainsi utiliser le JavaScript pour obtenir l'identifiant et la description de la 
liste a afficher dans la cellule du tableau. 



Utilisation du pattern session-in-view avec Hibernate 

Le pattern session-in-view, presente au chapitre 11, permet d'utiliser 1' initialisation 
tardive, ou lazy-loading, pour de meilleures performances. Cette methode, utile dans le 
cadre des JSP, reste entierement valable pour des composants AJAX. 

C'est de cette maniere que le Bean Spring tudu. web. dwr. impl .TodoListsDwrlmpl peut 
rechercher la liste des utilisateurs dans sa methode getTodol_istsUsers( ). En effet, la liste 
des utilisateurs est une collection en initialisation tardive, e'est-a-dire qu'elle n'est reel- 
lement recherchee en base de donnees qu'au moment oil elle appelee. 

Pour ce faire, il nous faut configurer le filtre de servlets d'Hibernate afin qu'il traite les 
requetes envoyees a DWR de la meme maniere qu'il traite les requetes envoy ees a Struts ou 
a Spring MVC. Cela se traduit par un double mapping dans le fichier WEB-INF/web.xml : 

<filter> 

<filter-name>Hibernate Session In View Filter</filter-name> 
<filter-class> 

org.springframework.onn.hibernate3.support.0penSessionInViewFilter 

</filter-class> 
</filter> 

<!-- configuration pour Struts --> 
<f i 1 ter-mapping> 

<filter-name>Hibernate Session In View Filter</filter-name> 

<url -pattern>*.action</url -pattern> 
</filter-mapping> 

<!-- configuration pour DWR --> 
<f i 1 ter-mapping> 

<filter-name>Hibernate Session In View Filter</filter-name> 

<url -pattern>/secure/dwr/*</url -pattern) 
</filter-mapping> 



Ameliorations apportees par script.aculo.us 

script.aculo.us est une bibliotheque d'effets speciaux qui n'est pas specifique a DWR ou 
meme a J2EE, mais qui s'integre bien a ces technologies. 

Le site Web ofhciel de script.aculo.us (http://script.aculo.us) propose de nombreux exemples 
et demonstrations, dont beaucoup sont realisees avec Ruby On Rails, un framework 
aujourd'hui tres populaire, qui integre script.aculo.us en standard. 
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Nous allons voir comment integrer script. aculo.us a DWR dans le cadre des Tudu Lists 
afin de realiser un site Web esthetiquement plus agreable. 

Installation 

Pour installer script.aculo.us, il faut en telecharger la derniere version et l'installer dans 
l'application Web comme n'importe quel fichier JavaScript. Pour Tudu Lists, nous avons 
choisi de l'installer dans le repertoire WebContent/scripts/scriptaculous. Afin de suivre 
les evolutions de cette bibliotheque, nous avons ajoute un fichier version.txt, qui stocke 
la version de la distribution utilisee. 

Nous avons ensuite importe les deux fichiers principaux de script.aculo.us dans le header 
de Tudu Lists, le fichier WEB-INF/jspf/header.jsp : 

<script type=" text/ javascript" 

src="${ctx}/scripts/scriptaculous/prototype. js"> 
</script> 

<script type=" text/ javascript" 

src="${ctx}/scripts/scriptaculous/scriptaculous. js"> 
</script> 

Le premier fichier, prototype.js, correspond a Prototype, un framework simplifiant le 
developpement JavaScript sur lequel script.aculo.us est fonde. 

Le deuxieme fichier, scriptaculous.js, importe l'ensemble des fichiers necessaires a 
1' utilisation de script.aculo.us. 

Nous avons choisi de placer ces deux fichiers dans le header de Tudu Lists afin de simpli- 
fier le developpement, sachant qu'une fois telecharges ils seront stockes dans le cache du 
navigateur client. Les importer dans chaque page JSP n'est done pas un handicapant en 
terme de charge serveur. 

Utilisation des effets speciaux 

L'utilisation des effets fournis par script.aculo.us est tres simple. En voici un exemple, 
provenant de la page de gestion des todos, WEB-INF/jsp/todos.jsp : 

function renderMenut ) { 
todos .getCurrentTodol_ists(replyCurrentTodol_ists ) ; 
Effect .Appear ( "todoListsMenuBody" ) ; 

} 

La bibliotheque d'effets speciaux s'utilise avec l'objet Effect, lequel possede un grand 
nombre d'effets, qui prennent en parametre l'identifiant du composant HTML a impac- 
ter. Dans 1' exemple ci-dessus, nous demandons un effet d' apparition sur le composant 
HTML todoListsMenuBody. 
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La liste complete de ces effets est disponible sur le site de script. aculo. us. II existe notam- 
ment des effets de fondu (Effect.Fade) et de disparition (Effect.Puff), qui ressemblent a 
ce que nous trouvons dans Microsoft PowerPoint pour afficher ou faire disparaitre des 
elements de presentation. 

Ces effets peuvent aussi etre utilises dans les evenements JavaScript, comme dans 
l'exemple suivant : 

<div oncl i ck="new Effect. Fade(this)"> 

Cliquez ici pour que cet element disparaisse. 
</div> 

Ces effets speciaux presentent les deux utilites majeures suivantes dans la construction 
d'une page AJAX : 

• lis permettent a l'utilisateur d' avoir une notification visuelle de ses actions. Les 
personnes habituees aux sites Web classiques peuvent etre desorientees devant un site 
Web AJAX. Grace a des effets tels que Effect. Shake, Effect. Pulsate ou 
Effect. Hi ghl ight, elles ont mieux conscience de ce qui se passe dans 1' application. 

• lis permettent a l'utilisateur d'attendre que les fonctions AJAX s'executent. Lorsque 
nous editons un todo, il est plus agreable d'avoir une boite de dialogue qui s'affiche en 
douceur, avec les elements deja prerenseignes. Sans effet special, nous n'aurions le 
choix qu'entre un site semblant peu reactif, si nous recherchons les informations avant 
d' afficher la boite de dialogue, ou un site avec des boites de dialogues vides se remplissant 
avec un temps de retard, dans le cas inverse. 

Ces effets speciaux sont done tres importants pour la qualite de 1' experience utilisateur. 



Utilisation avancee 

script.aculo.us permet de proposer des solutions qui n'etaient jusqu'a present disponibles 
que dans les applications de type client lourd. Parmi ces fonctionnalites avancees, 
script.aculo.us propose le glisser-deplacer, les listes a trier graphiquement et les champs 
HTML qui se remplissent via des appels cote serveur. 

Dans sa version 1.5, que nous utilisons dans le cadre de cet ouvrage, script.aculo.us 
s'integre mal a DWR pour ces fonctionnalites avancees. C'est la raison pour laquelle 
nous allons les etudier en dehors de l'etude de cas et de DWR. 

Edition de texte a chaud 

Cette fonctionnalite permet de transformer une chaine de caracteres normale en un 
champ de saisie HTML. Nous pouvons ainsi modifier certains elements d'une page en 
cliquant simplement dessus. 

En voici un exemple de code : 

<p id="texteModifiable">Ce texte est modifiable</p> 
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<script language="JavaScript"> 
new Ajax. InPl aceEditor( 'texteModifiable' , 
'${ctx}/tudu/example/saveText' ) ; 
</script> 

Le resultat de ce code est illustre a la figure 9.3. 



Figure 9.3 

Texte modifiable a chaud 



|Ce texte est modifiable! ok |cancei 



La fonction Ajax. InPlaceEditor prend en premier parametre l'identifiant du bloc HTML a 
modifier (un paragraphe dans notre exemple) et en second une URL qui sera chargee de 
traiter la requete. Cette fonction contourne done DWR, comme indique precedemment. 

L'URL appelee a pour role de sauvegarder le changement de texte. Elle recoit en POST 
le parametre val ue, contenant le nouveau texte a enregistrer, et doit renvoyer la chaine de 
caracteres a afficher. Cette derniere peut done etre differente du texte envoye, si celui-ci 
n'est pas valide, par exemple. Une simple servlet est parfaitement adaptee pour ce type 
de traitement. 

Creation d'une liste deroulante dynamique 

Cette fonctionnalite est souvent appelee Google Suggest, Google ayant popularise ce 
type de liste deroulante dans une version beta de son site. 

La figure 9.4 en illustre un exemple avec une recherche sur le mot-cle « j2ee ». 



Figure 9.4 
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De meme que la fonction precedente, cet exemple court-circuite DWR et s'utilise de la 
maniere suivante : 

<input type="text" id="utilisateurs" name="uti 1 i sateurs"/> 
| <div id="utilisateurs_autocomplete"X/div> 



Utilisation d'AJAX avec Spring 



Chapitre 9 



<script 1 anguage="JavaScri pt"> 
new Ajax. Autocompl eter( "util isateurs" , 

"uti 1 i sateurs_autocompl ete" , 

"${ctx}/tudu/exampl e/f indUsers" , 

{}); 
</script> 

La fonction Ajax.AutoCompleter prend en premier parametre l'identifiant de la zone de 
texte editable, en deuxieme parametre l'identifiant du layer DHTML servant a afficher 
les valeurs dynamiques, en troisieme parametre l'URL chargee de traiter la requete et en 
quatrieme parametre des options. 

L'URL traitant la requete va recevoir en methode POST le contenu du champ HTML. La 
cle utilisee en parametre est l'attribut name de la balise input. Cette URL devra retourner 
le contenu affiche dans le layer DHTML, nomme util isateurs_autocompl ete dans notre 
exemple, sous forme de liste HTML : 

<ul> 

<li>j2ee</li> 

<li>j2ee tuton'al</li> 
</ul> 

Cette fonctionnalite ameliore l'utilisabilite du site, mais elle est egalement extremement 
gourmande en ressources. Nous ne pouvons que conseiller l'utilisation d'un cache cote 
serveur. II existe plusieurs solutions adaptees pour ce type de besoin, en particulier Ehcache 
(http://ehcache.sourceforge.net), que nous presentons au chapitre 1 1, ou OSCache (http://www.open- 
symphony.com/oscache/), qui propose un filtre de servlet interessant pour cette situation. 

Si notre but est la creation d'un vrai moteur de recherche, l'utilisation de bases de 
donnees n'est pas recommandee, car elles sont lentes et mal adaptees a ce type de traite- 
ment. L'utilisation de Lucene (http://lucene.apache.org/) parait plus appropriee, d'autant que 
cette bibliotheque peut etre integree a Spring. Nous avons pu rencontrer l'architecte d'un 
site Internet francais a fort trafic, qui utilise la combinaison Spring/Lucene pour obtenir 
des temps de reponse inferieurs a 100 millisecondes par requete. De tels resultats rendent 
possible la creation d'un site Web de type Google Suggest en utilisant uniquement des 
technologies Java Open Source. 



Utilisation de Prototype 

Prototype est une bibliotheque JavaScript, disponible a l'adresse http://prototype.conio.net/. 
Elle est utilisee en interne par script.aculo.us, car elle fournit un ensemble d'utilitaires 
simplifiant la manipulation de l'arbre DOM et les appels AJAX. Pour un developpeur 
JavaScript, cette bibliotheque d'un investissement minime en apprentissage est certainement 
utile. 

Ses fonctions les plus simples et les plus utiles, qui ne sont pas specifiques a J2EE ou 
meme a AJAX, sont detaillees dans les sections suivantes. 
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La fonction $() 

La fonction $() est un raccourci vers la fonction JavaScript document. getElementByldO, 
qui est tres souvent utilisee en AJAX. En voici un exemple d'utilisation : 

<div id="exempleDiv"> 
<p>Bonjour!</p> 
</div> 

<script language="JavaScript"> 

var exemple = $( 'exempleDiv' ); 

al ert( exemple. innerHTML) ; 
</script> 

Cette fonction est capable de retourner un tableau d' elements si nous lui donnons en 
parametres plusieurs identifiants : 

var exemples = $( 'exempleDiv' , 'exempleDiv2' , 'exempleDiv3' ) ; 

for(i=0; Kexemples. length; i++) { 
al ert(exempl es[i ] .innerHTML) ; 

} 

La fonction $F() 

II s'agit la aussi d'un raccourci, capable de retrouver n'importe quel element d'un formu- 
laire HTML, quel que soit son type. 

Cela donne avec l'exemple precedent : 

<input type="text" id="exemplelnput" value="Bonjour! "/> 

<script language="JavaScript"> 

var exemple = $F( 'exemplelnput' ) ; 

alert(exemple) ; 
</scri pt> 

La fonction Try.theseQ 

Cette fonction est utile pour creer des sites Web robustes, capables d'afficher correcte- 
ment des pages Web malgre les problemes de compatibilite poses par le JavaScript. Nous 
en aurons certainement besoin si nous voulons utiliser AJAX sur un site disponible sur 
Internet. 

La fonction Try.theseO permet de tester plusieurs fonctions a la suite, jusqu'a ce que 
l'une d'elles marche correctement. En voici un exemple d'utilisation : 

function exemple(){ 
return Try.these( 
functionO { 
// fonctionnement normal. 

}, 
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functionO { 

// mode degrade, utilise si la premiere fonction a echoue 

) 

); 

} 



Conclusion 

Apres une introduction a AJAX et au Web 2.0, nous nous sommes arretes sur deux gran- 
des bibliofheques JavaScript complementaires, DWR et script.aculo.us. DWR permet 
d'utiliser cote client des Beans Spring provenant d'une application Java/J2EE en back- 
end, script.aculo.us permet d'ajouter des effets speciaux aux pages Web. La combinaison 
de ces differentes technologies permet de developper des sites Web attractifs, radicale- 
ment differents de ceux d'avant 2005. C'est la un changement important en terme de 
fonctionnalites et d'utilisabilite, qu'il va etre important de maitriser dans les annees a 
venir. 

Nous avons vu qu'avec cette boite a outils il n'etait pas tres difficile de creer des pages 
Web utilisant AJAX. Les difficultes rencontrees se trouvent plutot du cote de l'utilisation 
d'AJAX, qui presente deux inconvenients : cette technique bombarde les serveurs de 
requetes HTTP, mettant en danger leur montee en charge, et risque de troubler les utilisa- 
teurs habitues a des applications plus traditionnelles. A ces deux problemes, nous avons 
vu qu'il existait des solutions : monitoring des performances et tuning pour le premier, 
utilisation d'effets speciaux pour le second. 

AJAX est une technique simple d'emploi et bien outillee. Nous ne saurions trop 
conseiller aux concepteurs de sites Web de l'ajouter a leur arsenal technique. 
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Un portail est un site Web qui regroupe sur une me me page un grand nombre d' informa- 
tions interessant ses utilisateurs. Ces informations provenant de canaux differents, les 
pages des portails gerent differentes entites de presentation et de traitement autonomes, 
avec lesquelles elles interagissent. Ces solutions sont de plus en plus utilisees en entre- 
prise afin d'offrir sur une meme page les informations et services mis a disposition des 
utilisateurs. 

J2EE adresse la problematique des applications de portail par le biais de la specification 
portlet. Son composant de base, la portlet, presente des analogies avec celui de la specifi- 
cation servlet, la servlet. Les portlets s'appuient d'ailleurs sur cette derniere specification 
en l'enrichissant, afin de gerer plusieurs composants independants dans une meme page 
Web. 

A partir de la version 2.0, Spring fournit un support pour faciliter le developpement 
d' applications fondees sur la technologie portlet. II reprend et transpose a cet effet les 
mecanismes de Spring MVC. 

Ce chapitre detaille ces mecanismes et composants de Spring MVC repris dans le 
support des portlets par Spring. Afin de faciliter la comprehension de ce support de la 
specification portlet, nous reprenons volontairement le plan du chapitre 7, relatif a Spring 
MVC. 
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La specification portlet 

La specification portlet offre un cadre de developpement afin de creer des composants 
integrables dans des portails. Comme explique precedemment, un portail permet de 
regrouper sur une meme page Web plusieurs applications independantes, utilisant diffe- 
rentes sources de donnees. 

Les outils de portail integrant un conteneur de portlets afin de pouvoir utiliser les compo- 
sants applicatifs fondes sur les portlets. Le conteneur de portlets le plus utilise dans les 
portails est Pluto, de la fondation Apache, disponible a l'adresse http://portals.apache.org/ 
plutol. II correspond a 1' implementation de reference de la specification portlet. 

Les portails les plus utilises dans le monde Open Source sont JetSpeed, GridSphere et 
uPortal. Ces projets sont accessibles respectivement aux adresses http://portals.apache.org/ 
jetspeed-1/ et http://www.gridsphere.org/gridsphere/gridsphere et http://www.uportal.org/. 

La figure 10.1 donne un exemple de site utilisant un outil de portail. Les differentes zones 
correspondent a differentes portlets afhchant divers canaux d' information. 
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Portail de Vuniversiti de VEtat d 'Arizona utilisant uPortal 



Du fait que cette specification enrichit la specification servlet, les applications fondees 
sur les portlets doivent etre packagees sous forme d' archives WAR. 

Les portlets definissent deux points d'entree, dont le premier, render, adresse les proble- 
matiques de presentation. II est appele par le conteneur de portlets en cas de rafraichisse- 
ment global de l'affichage de la page du portail. Cet evenement peut survenir suite a une 
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modification des donnees affichees par une portlet, ce qui entraine un appel par ce point 
d' entree de toutes les portlets affichees dans la page. De ce fait, des mecanismes de cache 
sont couramment mis en oeuvre afin d'optimiser les temps de rafraichissement de l'affi- 
chage des pages du portail. 

La figure 10.2 illustre l'impact d'un rafraichissement de l'affichage d'une page sur toutes 
les portlets qu'elle contient. 
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Le second point d'entree, processAction, permet d'interagir avec une portlet afin d'effec- 
tuer des modifications, par exemple en utilisant des donnees envoyees par 1' intermediate 
d'un formulaire. Ce point d'entree n'adresse pas les problematiques de presentation des 
donnees et est done immediatement suivi par le rafraichissement de la page du portail, 
par le biais du point d'entree precedent. 

Ce rafraichissement est automatiquement declenche par le conteneur de portlets, comme 
l'illustre la figure 10.3. 
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Figure 10.3 

Mecanisme de traitement d'une action pour une portlet 
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L' interface Portlet du package javax.portlet comporte deux methodes, correspondant 
aux deux points d' entree precedemment decrits, comme le montre le code suivant : 

public interface Portlet ( 
void destroy( ) ; 

void inittPortletConfig config); 

void processAction(ActionRequest request, 

ActionResponse response); 
void render(RenderRequest request, 

RenderResponse response); 

} 

Les methodes init et destroy adressent la gestion du cycle de vie du composant. La 
methode init peut etre implementee afin d'ajouter des traitements d' initialisation fondes 
sur une instance de PortletConfig, qui materialise la configuration de la portlet dans le 
fichier portlet.xml, localise dans le repertoire WEB-INFA La methode destroy permet 
quant a elle de liberer les ressources utilisees avant que la portlet soit detruite. 

Les points d'entree de la portlet (methodes processAction et render) prennent en parametres 
des specialisations des classes Portl etRequest et Portl etResponse afin de pouvoir interagir 
respectivement avec la requete et la reponse. 

Notons l'existence de la classe GenericPortlet du package javax.portlet, similaire a la 
classe GenericServlet de la specification servlet. Elle fournit des methodes dediees afin 
de gerer les differents modes d'affichage de la portlet. 

Le code suivant montre 1' implementation d'une portlet fondee sur cette classe : 

public class TodoPortlet extends GenericPortlet { 
public void initCPortletConfig config) 

throws Portl etExcepti on, UnavailableException { 

super. init(config); 

String myParam = config. getlnitParameterC'myparam") ; 
(...) 

} 

(...) 

public void doView(RenderRequest request, 

RenderResponse response) 

throws Portl etExcepti on, IOException { 

request. setContentType( "text/html ") ; 

// Recuperation d'un todo a partir des parametres de 

//la requete 

Todo todo=getTodo( request) ; 
request. setAttribute( "todo" ,todo) ; 

// Affichage du todo dans une JSP 
PortletRequestDispatcher rd = 

get Portl etContext( ) .get Request Dispatcher 
"/todo. jsp" ) ; 
rd. incl ude(rReq, rRes) ; 

} 

} 
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Les applications fondees sur la technologie portlet ne peuvent utiliser directement les adresses 
pour la navigation. En effet, le conteneur de portlets utilisant sa propre strategie de gestion 
des adresses, la specification portlet impose l'utilisation des taglibs actionURL et renderURL 
afin d'interagir avec les differentes ressources gerees par le conteneur de portlets. 

Le code suivant illustre leur utilisation dans une page JSP : 

<%@ taglib pref ix="portl et" uri="http://java. sun.com/portlet" %> 



<!- Execution d'une action pour la portlet --> 
<form method="post" action="<portlet:actionURL> 

<portlet:param name="action" val ue="saveTodo"/> 
<portlet:param name="todoId" value="10"/> 
</portlet:actionURL>"> 
(...) 
</form> 

<!-- Affichage de la portlet --> 

<a href="<portlet:renderURL> 

<portlet:param name="action" val ue="showTodo"/> 
<portlet:param name="todoId" value="10"/> 
</portlet:renderURL>">Visualisation d'un Todo</a> 



Le support des portlets de Spring 

Le support des portlets de Spring implemente un framework MVC de type 2, qui 
s'appuie sur la technologie portlet afin d'adresser au mieux la resolution de ce pattern 
dans les applications de portail. 

Dans le contexte de la technologie portlet, 1' implementation de ce pattern se divise en 
deux parties, traitant respectivement les requetes de modification et celles d' affichage, 
comme l'illustre la figure 10.4. 
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Le pattern MVC de type 2 reprend les concepts de base de Spring MVC, mais les adapte a la 
technologie portlet. II utilise pour cela toutes les fonctionnalites du conteneur leger de 
Spring, notamment pour configurer les composants du MVC ainsi que leurs dependances. 

Les points cles de Spring MVC repris et adaptes pour le support des portlets sont les suivants : 

• utilisation d'un controleur facade implements par une portlet et utilisant un sous- 
contexte de celui de 1' application Web ; 

• specification de differentes strategies d'aiguillage des requetes vers les controleurs ; 

• fonctionnalites permettant de realiser le mappage de donnees dans des Beans ainsi que 
leur validation ; 

• definition de differents types de controleurs afin de resoudre au mieux les differentes 
situations ; 

• specification de differentes strategies de resolution des vues ; 

• support de differents types de vues. 

Dans la suite du chapitre, nous designons le framework Web de Spring par Spring MVC 
et le framework portlet par support portlet. 

Puisque le support portlet reprend les concepts de Spring MVC, sa prise en main est 
facile pour les utilisateurs maitrisant ce framework. Le support portlet reutilise de fait 
differents composants de Spring MVC, notamment pour la gestion des vues. 

La figure 10.5 illustre les differentes briques du support, avec en gris les parties de Spring 
MVC reutilisees. 
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Initialisation du support portlet 

L' initialisation du support portlet se realise en deux parties et s'effectue essentiellement 
dans les fichiers web.xml et portlet.xml, localises dans le repertoire WEB -INF/. Le 
framework utilise des mecanismes issus des specifications servlet et portlet. 



Gestion des contextes 

Dans les applications utilisant la technologie portlet, les contextes sont geres de la meme 
maniere que dans les technologies Web classiques. 

Une hierarchie de contextes est mise en oeuvre, a la difference pres que le contexte situe 
au bas de la hierarchie correspond non plus a celui de Spring MVC, fonde sur les 
servlets, mais a celui du support portlet, comme l'illustre la figure 10.6. 

Figure 10.6 
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Le contexte partage et celui de 1' application Web sont charges de la meme maniere 
qu'avec Spring MVC et Struts (pour plus de details, voir les sections concernees des 
chapitres 6 et 7). 

Le chargement du contexte MVC portlet est rattache a la portlet principale du framework 
d'une maniere analogue a Spring MVC. Le nom du fichier de configuration de ce contexte 
doit etre specifie par 1' intermediate du parametre d'initialisation contextConf i gLocati on pour 
la classe Di spatchPortl et, comme le montre le code suivant, issu du fichier portlet.xml : 

<portl et-app> 
<portlet> 
(...) 

<portlet-cl ass> 

org. springframework. web. portlet. Dispatcher Port let 
</portl et-cl ass> 
<init-param> 

<name>contextConf i gLocati on</name> 
<value>/WEB-INF/tudu-portlet.xml</value> 
</init-param> 
(...) 
</portlet> 
</portlet-app> 
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Initialisation des entites de base 

Contrairement a Spring MVC, le support portlet necessite la mise en oeuvre de deux entites 
afin de permettre respectivement Faeces a 1' application et l'afnchage des donnees. 

Contrdleur fagade 

Le framework Spring MVC implementant le pattern MVC de type 2, il doit mettre en 
ceuvre un controleur facade afin de diriger les traitements vers des classes designees par 
le terme Control 1 er dans le support portlet et Spring MVC. 

L'objectif du support est de transposer ce mecanisme pour la technologie portlet. De 
cette maniere, le developpement d' applications de portail suit les memes principes que 
ceux de Spring MVC. 

De ce fait, le controleur facade n'est plus implements par une servlet mais par une port- 
let. Son type correspond desormais a la classe DispatchPortlet localisee dans le package 
org. springf ramework. web. port let. 

Le code suivant donne une configuration possible de cette entite dans le fichier portlet.xml : 

<portlet-app> 
<portlet> 

<portl et-name>tudu</portlet-name> 
<portl et-cl ass> 

org. springf ramework. web. portlet. DispatcherPortlet 
</portl et-cl ass> 
<init-param> 

<name>contextConf igLocation</name> 

<value>/WEB-INF/tudu-portlet.xml</val ue> 
</init-param> 
<supports> 

<mime-type>text/html </mime-type> 

<portl et-mode>view</portlet-mode> 

<portl et-mode>help</portlet-mode> 
</supports> 
<portlet-info> 

<title>Tudu</title> 
</portlet-info> 
</portlet> 
</portl et-app> 

Comme avec Spring MVC, il est possible de definir dans la meme application plusieurs 
controleurs facade afin d'implementer differents modules independants. 

Gestion des vues 

Pour mettre en oeuvre les vues, le support portlet utilise une servlet dediee, dont nous 
detaillons l'utilite dans la suite du chapitre. 

Cette servlet est de type ViewRendererServlet pour le package org.springfra- 
mework. web. servlet et est configuree dans le fichier web.xml de la maniere suivante : 

<web-app> 
(...) 
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<servlet> 

<servlet-name>ViewRendererServl et</servlet-name> 
<servlet-class> 

org.springf ramework.web.servlet.ViewRendererServlet 
</servl et-cl ass> 

<load-on-startup>K/load-on-startup> 
</servl et> 



<servlet-mapping> 

<servlet-name>ViewRendererServl et</servl et-name> 

<url -pattern>/WEB-INF/servl et/view</url -pattern> 
</servlet-mapping> 
(...) 
</web-app> 

La valeur specifiee dans la balise url -pattern pour la servlet doit correspondre a celle 
utilisee par la portlet DispatchPortlet. Dans notre exemple, nous avons utilise la valeur 
par defaut /WEB-INF/servlet/view. II est cependant possible d'utiliser une autre valeur en 
utilisant la propriete d' initialisation viewRendererUrl de la portlet precedemment decrite. 



Traitements des requetes 

Le support portlet de Spring met en oeuvre des mecanismes similaires a ceux de Spring 
MVC afin de rediriger les requetes vers la bonne entite de traitement. 

II doit pour cela prendre en compte les specificites de la technologie portlet et ne peut 
s'appuyer sur les URL, a la difference de Spring MVC. 

Selection du controleur 

Le support portlet de Spring offre une entite de base permettant de selectionner le contro- 
leur a utiliser en fonction de la requete. L' interface correspond au type Handl erMappi ng du 
package org. spring-framework. web. portlet, telle que definie par le code suivant : 

public interface HandlerMapping { 
Handl erExecutionChain getHandler( 

PortletRequest request) throws Exception; 

La difference principale avec Spring MVC vient du parametre de la methode getHandler, 
qui est desormais de type PortletRequest. 

Le support dispose de deux implementations de cette interface, localisees dans le 
package org. springf ramework.web. portl et. handler. 

Contrairement aux servlets, l'aiguillage ne peut s'appuyer sur une adresse d'acces pour 
determiner le controleur puisque le conteneur de portlets a la responsabilite de les gerer 
en interne. L adresse ne peut done constituer un critere de selection. 
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Le support portlet peut cependant utiliser les modes d'affichage d'une portlet et/ou un 
parametre afin de determiner le controleur impacte. Le support portlet definit pour cela 
deux implementations de l'interface HandlerMapping. La premiere utilise uniquement le 
mode comme moyen de selection. Cette implementation correspond a la classe Portlet- 
ModeHandlerMapping et se configure par l'intermediaire d'une table de hachage etablissant 
la correspondance entre les modes et les controleurs. 

Le code suivant, issu du fichier tudu-portlet.xml, localise dans le repertoire WEB-INF/ 
context/portlet/, donne un exemple de mise en oeuvre de cette premiere implementation : 

<beans> 
(...) 

<bean id="portl etModeHandl erMapping" cl ass="org.springf ramework 
.web.portlet.handler.PortletModeHandlerMapping"> 
<property name="portletModeMap"> 
<map> 

<entry key="view"> 

<ref bean="showTodoLi stsControl ler"/X/entry> 
<entry key="help"> 

<ref bean="showTodol_i stsControl ler"/X/entry> 

</map> 
</property> 
</bean> 
(...) 
</beans> 

La seconde implementation est plus fine et combine le mode avec un parametre de 
requete afin de selectionner le controleur. Elle correspond a la classe PortletModeParame- 
terHandl erMapping et se configure par le biais de deux tables de hachage imbriquees, 
comme dans le code suivant, tire du meme fichier que precedemment : 

<beans> 
(...) 

<bean id="portletModeParamHandlerMapping" class="org 

.springf ramework. web. portlet. handler 
. Portl etModeParameterHandlerMapping"> 
<property name="portletModeParameterMap"> 

<map> 

<entry key="view"> 
<map> 

<entry key="showTodol_ists"> 

<ref bean="showTodol_i stsControl 1 er"/X/entry> 
<entry key="editTodol_ist"> 

<ref bean="editTodoListControl ler"/X/entry> 
(...) 
</map> 
</entry> 
</map> 
</property> 
</bean> 
(...) 
</beans> 
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Le support portlet offre la possibility d'utiliser conjointement plusieurs implementations 
de l'interface HandlerMapping en mettant en oeuvre un mecanisme de chainage de 
HandlerMapping. Cette fonctionnalite reprend les principes de Spring MVC pour les 
ViewResol ver en les adaptant pour l'aiguillage des requetes. 

La configuration de l'ordre des implementations de HandlerMapping se realise par le biais 
de la propriete order, comme dans le code suivant : 

<beans> 
(...) 

<bean id= "portl etModeHandlerMapping" class="org.springframework 
.web. port let.handler.PortletModeHandlerMapping"> 
<property name="order" value="20"/> 
(...) 

</bean> 

<bean id="portletModeParamHandlerMapping" class="org 

. springf ramework. web. port 1 et . handl er 
. Portl etModeParameterHandl erMapping"> 
<property name="order" value="10"/> 
(...) 
</bean> 
(...) 
</beans> 



Interception des requetes 

Dans le support portlet, les interceptions se fondent sur les memes principes que dans 
Spring MVC. L'entite de base des controleurs suit la meme structure que l'interface 
Handl erlnterceptor, localisee dans le package org.springframework.web.servlet. La seule 
difference provient des parametres des differentes methodes, puisque la technologie portlet 
possede ses propres entites de representation des requetes et des reponses. 

L'entite de base des intercepteurs pour le support portlet est l'interface Handl erlntercep- 
tor, localisee desormais dans le package org. springf ramework. web. portlet, comme le 
montre le code suivant : 

public interface Handlerlnterceptor { 

boolean preHandl e( Portl etRequest request, 

Portl etResponse response, Object handler) throws Exception; 
void postHandle(RenderRequest request, RenderResponse response, 
Object handler, ModelAndView modelAndView) throws Exception; 
void afterCompletion(PortletRequest request, 

Portl etResponse response. Object handler, Exception ex) 

throws Exception; 

} 

La classe HandlerlnterceptorAdapter du package org. springf ramework. web. port- 
let . handl er facilite l'utilisation de cette interface en fournissant une implementation par 
defaut fondee sur le pattern adaptateur. 
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Comme dans Spring MVC, la configuration des intercepteurs se realise au niveau du 
parametrage des differentes implementations de HandlerMapping, comme le montre le 
code suivant, tire du fichier tudu-portlet.xml : 

<beans> 
(...) 

<bean id="parameterMappingInterceptor" class="org 

.springf ramework. web. portlet. handler 
. ParameterMappingInterceptor"/> 

<bean id="portletModeParamHandlerMapping" class="org 

.springf ramework. web. portlet. handler 
. Portl etModeParameterHandlerMapping"> 

(...) 

<property name="interceptors"> 
<list> 

<ref bean="parameterMippingInterceptor"/> 

</list> 
</property> 
(...) 

</bean> 
(...) 
</beans> 

Le support fournit egalement l'intercepteur ParameterMappinglnterceptor afin d'appeler 
automatiquement la methode setRenderParameter de l'instance de la classe ActionResponse. 
Ce mecanisme est particulierement interessant en cas d'execution d' actions par les 
controleurs afin que le meme controleur soit utilise pour afficher le resultat de la modification. 

Dans ce contexte de passage d'une requete d'action a une requete d'afnchage, notons les 
interessantes possibilites fournies par la classe utilitaire Portl etUti Is du package 
o rg. springf ramework. web. port let.util . 

Les differents types de controleurs 

Le support portlet definit plusieurs implementations de controleurs afin d'adresser differents 
cas d'utilisation, tels que la gestion de la soumission des formulaires. 

Bien que ce support reprenne les mecanismes de Spring MVC, le panel de types de 
controleurs offerts est bien moins riche que celui du framework. 

Les controleurs simples 

Le support portlet s'appuie sur une interface de base, nominee Control 1 er et localisee dans le 
package org. springframework. web. portlet. mvc. Cette derniere est similaire a celle de Spring 
MVC, son unique difference provenant de son adherence a la technologie portlet. 

Cette interface definit deux points d' entree, comme dans le code suivant : 

public interface Controller { 

ModelAndView handl eRenderRequest( RenderRequest request, 

RenderResponse response) throws Exception; 
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void handleActionRequesttActionRequest request, 

ActionResponse response) throws Exception; 

} 

La premiere methode, handl eRenderRequest, realise les traitements d'affichage et est appe- 
lee en cas de rafraichissement de l'affichage. Elle utilise en parametre des objets imple- 
mentant RenderRequest et RenderResponse. Elle renvoie un objet de type Model AndView, loca- 
lise dans le package org. springframework. web. port let afin de selectionner la vue a utiliser 
et de specifier le contenu du modele a utiliser. 

La seconde methode, handl eActionRequest, prend en compte les traitements de modification 
et est appelee lors d'une action. Elle utilise des objets implementant Acti onRequest et Acti on- 
Response mais ne possede pas de type de retour, contrairement a la methode precedente. 

Lors de 1' utilisation de cette seconde methode, une ligne de traitement peut etre ajoutee 
afin de specifier le parametre action, qui permet de selectionner le controleur a utiliser 
afin de rafraichir l'affichage de la portlet. 

Le code suivant donne un exemple de mise en oeuvre de ce mecanisme : 

public void handleActionRequesttActionRequest request, 

ActionResponse response) throws Exception { 

(...) 

response. setRenderParameter( "acti on", "showTodos") ; 

} 

Le support portlet offre egalement une classe de base abstraite afin de faciliter 1' implemen- 
tation des controleurs simples. Elle se nomme AbstractController et est localisee dans le 
package org. springframework. web. portlet. tnvc. Le developpeur doit alors utiliser les metho- 
des handl eActionRequestlnternal et handl eRenderRequestlnternal, qui correspondent respec- 
tivement aux methodes handl eActionRequest et handl eRenderRequest decrites precedemment. 
Cette classe offre des supports relatifs au controle des sessions et au cache. 

Le code suivant donne un exemple d'utilisation d'un controleur qui l'utilise : 

public class ShowTodoListsController extends AbstractController { 
(...) 

public ModelAndView handleRenderRequestlnternal ( 

RenderRequest request, 
RenderResponse response) 

throws Exception { 

User user = userManager.findLlser(getUser( ) ) ; 
Collection<TodoList> todoLists = user.getTodoLists( ) ; 
return new Model AndView ("todolists " , "todol ists" , todoLists) ; 

} 



(...) 

} 
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Les contrdleurs de gestion de formulaire 

Le support portlet met en ceuvre les memes mecanismes que Spring MVC pour afficher 
les donnees des formulaires et les traiter. II s'appuie pour cela sur 1' implementation 
Simpl eFormControl 1 er, localisee dans le package org. springf ramework.web.portl et. 

Ce controleur doit prendre en compte les specificites de la technologie portlet en matiere 
de rafraichissement de 1' affichage et de recuperation des donnees de formulaire en vue 
d'un traitement. 

Affichage du formulaire 

Le support portlet offre le me me cycle de traitements quant a 1' affichage du formulaire 
que Spring MVC. Tous les traitements sont realises au cours d'une unique requete, de 
type render pour le controleur. 

La figure 10.7 illustre les differentes etapes du cycle de traitements permettant d' afficher 
le formulaire. 



Figure 10.7 

Enchainement des methodes 
d' affichage des donnees 
d'un formulaire 
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onBindOnNewForm 
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Vue 



Les noms de methodes sont les memes que ceux utilises par Spring MVC et correspon- 
dent aux memes problematiques (pour plus de detail sur ces methodes, voir le chapitre 7, 
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relatif a Spring MVC). Leurs signatures peuvent cependant legerement differer, du fait 
des specificites de la technologie portlet. 

Le code suivant illustre la mise en oeuvre de la partie du controleur permettant d'af richer 
un formulaire : 

public class EditTodoListController extends SimpleFormController { 
(...) 

protected void initBinder(PortletRequest request, 

Portl etRequestDataBinder binder) throws Exception { 

(...) 

} 

protected Object formBackingObject( 

Portl etRequest request) throws Exception { 

String listld = request. getParameter( "1 istld" ) ; 
return todoListsManager .f indTodoLi st(l istld) ; 

} 



protected Map referenceData( Portl etRequest request. 

Object cms. Errors errors) throws Exception { 

(...) 



(...) 

} 

Soumission du formulaire 

L'enchainement des traitements de gestion de la soumission d'un formulaire est quasi- 
ment identique a celle de Spring MVC, a l'exception du nom de la methode onSubmit, qui 
devient onSubmitAction avec le support portlet, et de la facon d'afficher les vues par le 
biais d'une requete de type render. 

La soumission se realise en deux etapes : un premier appel a un controleur pour traiter les 
donnees soumises et un second appel au meme ou a un autre controleur pour l'affichage 
du resultat (voir figure 10.8). 

Le code suivant illustre la mise en oeuvre de ces mecanismes pour traiter les donnees du 
formulaire : 

public class EditTodoListController extends SimpleFormController ( 
(...) 



public void onSubmitAction(ActionRequest request, 

ActionResponse response, Object command, 
BindException errors) throws Exception { 

TodoList todoList = (TodoList)command; 
todoLi stsManager .updateTodoList(todoLi st) ; 

} 
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En cas de succes des traitements d'une soumission de donnees de formulaire, le contro- 
leur laisse la main au developpeur afin de specifier le controleur qui doit poursuivre les 
traitements. Si rien n'est specifie, le controleur par defaut est utilise, mais il est possible 
d'en specifier un explicitement par l'intermediaire de la methode setRenderParameter de 
la classe PortletResponse, comme dans le code suivant : 

public void onSubmitAction(ActionRequest request, 

ActionResponse response, 
Object command. 



Figure 10.8 

Enchatnement des methodes 
de soumission des donnees 
d'un formulaire 
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BindException errors) throws Exception { 
TodoList todoList = (TodoLi st)command ; 
todoLi stsManager .updateTodoLi st (todoList) ; 
response. setRenderParameterC'acti on". "editTodoList") ; 

} 

L'intercepteur ParameterMappinglnterceptor peut egalement etre mis en oeuvre a cet effet. 



Gestion des exceptions 

Le support portlet de Spring reprend les memes principes que Spring MVC ainsi que les 
memes noms pour les entites relatives. Les interfaces de Spring MVC ne peuvent toute- 
fois etre reprises en l'etat, puisque les conteneurs de portlets imposent respectivement 
l'utilisation des interfaces PortletRequest et Portl etResponse (et leurs derivees) alors que 
les conteneurs de servlets s'appuient sur les interfaces ServletRequest et Servl etResponse 
(et leurs derivees). 

Par defaut, les exceptions sont remontees directement dans le conteneur de portlets, mais 
il est possible de modifier ce comportement par 1' intermediate de l'interface Handler- 
ExceptionResolver, localisee dans le package org. springf ramework. web. portlet, comme le 
montre le code suivant : 

public interface HandlerExceptionResolver { 

ModelAndView resolveException(RenderRequest request, 

RenderResponse response, Object handler, Exception ex); 

} 

Le developpeur peut choisir d'utiliser ses propres implementations ou de mettre en 
oeuvre la classe SimpleMappingExceptionResolver du package org. springf ra- 
mework. web. portlet. handler fournie par le framework. Cette derniere permet de confi- 
gurer les vues a utiliser en fonction des exceptions levees. L exception est alors stockee 
dans la requete avec la cle exception, la rendant ainsi disponible pour un eventuel affi- 
chage. 

Ce mecanisme se configure de la maniere suivante dans le fichier tudu-portlet.xml : 

<bean id= "except ionResol ver" cl ass=" org. springf ramework. web 

. portlet. handler. Si mpleMapping Except i on Resol ver"> 
<property name="defaultErrorView" val ue="def Error"/> 
<property name="exceptionMappings"> 
<props> 

<prop key="javax. portlet. Portl etSecuri ty Except i on "> 

notAuthorized 
</prop> 

<prop key=" j a vax. portlet. Una vai 1 abl eExcepti on "> 

notAvai 1 abl e 
</prop> 
</props> 
</property> 
</bean> 
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Gestion de la vue 

La gestion de la vue reprend entierement les mecanismes de Spring MVC, en utilisant les 
interfaces ViewResolver et View du package org. spring-framework. web. servlet. view ainsi 
que leurs implementations. La configuration des vues se realise done de la meme maniere 
que dans Spring MVC. 

Le code suivant donne un exemple de configuration tire de Tudu Lists et fonde sur les 
technologies JSP et JSTL : 

<bean id="viewResolver" class="org.springframework.web 

.servlet .view. Internal ResourceViewResol ver"> 
<property name="viewCl ass" 

va 1 ue=" org. spring-framework, web. servlet. view. Jstl View" /> 
<property name="prefix" value="/WEB-INF/jsp/"/> 
<property name="suffix" val ue=" . jsp"/> 
</bean> 

La figure 10.9 illustre l'interaction entre la portlet DispatchPortlet et la servlet ViewRende- 
rerServl et. 



PortletDispatcher 






Appel de la methode render 
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ViewRendererServlet 



renderView 



Figure 10.9 

Mecanismes de traitement de la vue 
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Comme le support portlet reutilise les mecanismes et classes de Spring MVC relatives a 
la gestion des vues, 1' execution de la vue selectionnee doit etre executee en dehors de la 
classe DispatcherPortlet, puisque 1' implementation de la vue attend en parametre des 
instances de HttpServl etRequest et HttpServl etResponse. Cette portlet resout la vue a utili- 
ser puis delegue les traitements d'execution de la vue a la servlet ViewRendererServlet, 
developpee specifiquement a cet effet. 

Notons que les traitements de resolution de la vue se deroulent quand meme dans la port- 
let Di spatchPortl et. Cette derniere stocke ensuite dans la requete le contexte MVC relatif 
a la portlet, ainsi que 1' instance de la vue selectionnee et les elements du modele, arm de 
les rendre disponibles dans la servlet precedemment citee. 

Pour finir, remarquons que toutes les taglibs de Spring MVC sont utilisables par le 
support portlet, notamment ceux relatifs a la gestion des formulaires. 

Tudu Lists : utilisation d'un conteneur de portlets 

Dans le cadre de notre etude de cas, nous decidons de migrer une partie de 1' application 
Tudu Lists arm de la faire fonctionner dans un portail ou un conteneur de portlets. Pour 
cela, nous utilisons un projet specifique, Tudu-Portlet. 

Pour simplifier 1' application et rendre l'exemple plus simple, 1' application n' utilise ni la 
technologie AJAX, ni Acegi Security. Nous repartons de 1' application fondee sur Spring 
MVC afin de reutiliser au maximum son code. 

L' application migree met en oeuvre les fonctionnalites d'affichage et de modification de 
todos dans une portlet en reutilisant les composants services metier et d'acces aux 
donnees de Tudu Lists. 

Configuration de /'application 

L' application migree necessite la configuration des differents contextes de Spring, ainsi 
que la mise en ceuvre d'une servlet dediee afin d'afficher la presentation, en reutilisant les 
composants de Spring MVC. 

Les contextes 

Le premier contexte correspond a celui de 1' application Web. II est charge par l'interme- 
diaire de la classe ContextLoaderListener et est configure avec les fichiers dont le nom 
correspond a /WEB-INF/applicationContext*.xml. 

Ce contexte est configure de la meme maniere que dans Spring MVC dans le fichier 
web.xml du repertoire WEB-INF/, comme le montre le code suivant : 

<web-app id="WebApp_ID"> 

<context-param> 

<param-naine>contextConf igLocation</param-name> 

<param-val ue>/WEB-INF/appl icationContext*.xml </param-val ue> 

</context-param> 
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<listener> 

<listener-class> 

org. spring-framework, web. context. Context Loader Listener 
</listener-class> 
</l istener> 
(...) 
</web-app> 

Le second contexte est specifique du support portlet. II est configure et charge par le biais 
de la portlet DispatchPortlet. Le fichier utilise a cet effet se nomme portlet.xml et est 
localise dans le meme repertoire que precedemment. Le code de la configuration relative 
a ce contexte est le suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<portlet-app 

xmlns="http:// java.sun.com/xml /ns/portlet/portlet-app_l_0.xsd" 

xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 

xsi :schemaLocation=" 

http://java.sun.com/xml /ns/portlet/portlet-app_l_0.xsd 
http://java.sun.com/xml /ns/portlet/portlet-app_l_0.xsd" 

version="1.0"> 

<portlet> 

<portl et-name>tudu</portlet-name> 
<portl et-cl ass> 

org. springframework. web. portlet. Dispatcher Portlet 
</portl et-cl ass> 
<init-param> 

<name>contextConf i gLocati on</name> 

<value>/WEB-INF/tudu-portlet.xml</value> 
</init-param> 
<supports> 

<mime-type>text/html </mime-type> 

<portl et-mode>view</portlet-mode> 

<portlet-mode>help</portlet-mode> 
</supports> 
<portlet-info> 

<title>Tudu</title> 
</portlet-info> 
</portlet> 
</portl et-app> 

La servlet de presentation 

Comme explique precedemment, le support portlet necessite la mise en ceuvre de la 
servlet ViewRendererServlet afin de reutiliser les mecanismes de gestion des vues de 
Spring MVC. 
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Cette servlet doit etre configuree dans le fichier web.xml precedemment cite, comme 
indique dans le code suivant : 

<web-app i d="WebApp_ID"> 
(...) 

<servlet> 

<servlet-name>ViewRendererServl et</servlet-name> 
<servlet-class> 

org. spring-framework, web. servlet. ViewRendererServlet 
</servl et-cl ass> 

<load-on-startup>K/load-on-startup> 
</servl et> 

(...) 

<servlet-mapping> 

<servlet-name>ViewRendererServl et</servlet-name> 
<url -pattern>/WEB-INF/servl et/view</url -pattern> 
</servlet-mapping> 
</web-app> 



Implementation des controleurs 

Les differents controleurs du support portlet de Spring permettent d'afficher et de modi- 
fier des listes de todos et des todos et de realiser aussi bien un affichage de donnees 
qu'une gestion de formulaires. 

Le controleur simple 

Tudu Lists utilise un controleur simple pour afficher l'ensemble des listes des todos pour 
un utilisateur. II est implements par 1' intermediate de la classe ShowTodoListsController 
du package tudu. web et s'appuie sur la classe AbstractController, comme le montre le 
code suivant : 

public class ShowTodoListsController extends AbstractController ( 

private UserManager userManager; 

private TodoLi stsManager todoListsManager; 

public ModelAndView handl eRenderRequestlnternal ( 

RenderRequest request, RenderResponse response) 

throws Exception { 
User user = userManager. findUser(getUser( )) ; 
Collection<TodoList> todoLists = user.getTodoLists( ) ; 
return new Model AndViewC'todolists" , "todol ists" , todoLists) ; 

} 



(...) 

} 
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Ce controleur correspond a l'identifiant showTodo Lists et est configure pour etre accessible 
en mode « view ». II correspond egalement au controleur par defaut utilise par la portlet. 

Le mode d'acces ainsi que le controleur sont configures dans le fichier tudu-portlet.xml : 

<bean id="showTodoLi stsControl 1 er" 

cl ass="tudu. web. ShowTodoLi stsControl ler"> 

<property name="userManager" ref="userManager"/> 

<property name="todoListsManager" ref="todoListsManager"/> 
</bean> 

(...) 

<bean id= "portl etModeParameterHandl erMapping" 

cl ass= "org. springf ramework. web. port 1 et 

. handl er. Portl etModeParameterHandl erMapping" > 
<property name="order" value="10"/> 
<property name="portletModeParameterMap"> 
<map> 

<entry key="view"> 
<map> 

<entry key="showTodoLists"> 

<ref bean="showTodoLi stsControl 1 er"/> 

</entry> 
(...) 
</map> 
</entry> 
</map> 
</property> 
</bean> 

<bean id="portletModeHandl erMapping" cl as s=" org. springf ramework 

.web. port let. handler. Portl etModeHandlerMapping"> 
<property name="order" value="20"/> 
<property name="portletModeMap"> 
<map> 

<entry key="view"> 

<ref bean="showTodoLi stsControl 1 er"/X/entry> 

</map> 
</property> 
</bean> 

Le controleur utilise la vue d'identifiant todol i sts. Cette derniere est resolue par l'interme- 
diaire de laclasse Internal ResourceViewResol ver, implementation de 1'interface ViewResolver, 
et correspond done a la page JSP todolists.jsp localisee dans le repertoire WEB-INF/jsp. 

Le code suivant illustre le contenu de cette page, qui permet d'afficher la liste des listes 
de todos et definit les liens vers les pages de detail : 

<%@ page contentType="text/html " i sELIgnored="fal se" %> 

<%@ taglib prefix="c" uri="http://java. sun.com/jsp/jstl/core" %> 

<%@ taglib prefix="fmt" uri="http://java. sun.com/jsp/jstl/fmt" %> 

<%@ taglib pref ix="portl et" uri="http://java. sun.com/portlet" %> 
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List of todolists:<br/Xbr7> 
<c:forEach items="${todolists}" var="todol ist"> 
- <a href="<portlet:renderURL> 

<portlet:param name="action" val ue="showTodos"/> 
<portlet:param name="id" 

val ue="${todol 1st. 1 i stld}'7> 
</portlet:renderURL>"> 
<c:out value="${todolist.listId)"/> 
</a>: <c:out value="${todolist.name}"/><br/Xbr/> 
</c:forEach> 

Le controleur de gestion de formulaire 

La mise en ceuvre d'une entite de gestion de formulaire comporte les memes etapes 
qu'avec Spring MVC. 

Rappelons les differentes taches a realiser : 

• etendre la classe SimpleFormController (repere Q) ; 

• surcharger la methode formBackingObject afin de charger les donnees du formulaire 
(repere ©) ; 

• redefinir la methode onSubmitAction afin de traiter les donnees soumises par le formu- 
laire (repere Q) avec la methode HTTP POST par l'intermediaire d'une requete de 
type action ; 

• configurer le controleur ainsi que les vues utilisees. 

Le code suivant montre 1' implementation du controleur de formulaire EditTodoList- 
Control ler du package tudu.web, qui permet de modifier les donnees d'une liste de todos : 

public class EditTodoListController 

extends SimpleFormController {<-© 

(...) 

public void onSubmitAction(ActionRequest request, 

ActionResponse response, Object command, 
BindException errors) throws Exception {<-© 

TodoList todoList = (TodoLi st)command ; 
todoLi stsManager .updateTodo List (todoList) ; 

} 

protected Object formBackingObject( 

PortletRequest request) throws Exception {<-© 

String listld = request. getParameter( "1 istld" ) ; 
return todoLi stsManager. findTodoListd istld) ; 

} 



(...) 

} 
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Ce controleur doit etre configure dans le fichier tudu-portlet.xml afin de specifier ses 
dependances ainsi que ses proprietes relatives au MVC, comme le montre le code 
suivant : 

<bean id="edi tTodoListControl 1 er" 

cl ass="tudu.web. Edi tTodoListControl 1 er"> 
<property name="todoLi stsManager" ref="todoLi stsManager"/> 
<property name="commandName" value="todolist"/> 
<property name="commandCl ass" 

val ue="tudu. domain .model .TodoList"/> 
<property name="formView" value="editTodoList"/> 
</bean> 

Une entree doit egalement etre ajoutee au Bean portletModeParameterHandlerMapping afin 
que le controleur puisse etre accede a partir d'une page JSP : 

<bean id="parameterMappingInterceptor" cl ass="org.springf ramework 
. web. portlet. handler. Pa rameterMapping I nterceptor"/> 

<bean id="portletModeParameterHandlerMapping" class="org 

. springf ramework. web. port 1 et . handl er 
. Portl etModeParameterHandl erMapping"> 
<property name="order" value="10"/> 
<property name="interceptors"> 

<1 istXref bean="parameterMappingInterceptor"/X/l ist> 
</property> 

<property name="portletModeParameterMap"> 
<map> 

<entry key="view"> 
<map> 
(...) 

<entry key="editTodol_ist"> 

<ref bean="edi tTodoListControl ler"/> 
</entry> 
(...) 
</map> 
</entry> 
</map> 
</property> 
</bean> 

La mise en oeuvre de l'intercepteur ParameterMappinglnterceptor permet d'utiliser le 
meme controleur afin de construire l'affichage de la portlet apres un traitement correct 
des donnees soumises par le formulaire. 

Notons qu'il serait egalement possible de mettre en ceuvre les mecanismes de validation 
des donnees du formulaire de la meme maniere qu'avec Spring MVC en utilisant 
l'abstraction Validator. 
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Le controleur utilise l'identifiant de vue editTodoList pour afficher le formulaire. Cette 
vue est resolue par le meme ViewResolver que precedemment et correspond done a la 
page JSP editTodoList.jsp localisee dans le repertoire WEB-INF/jsp/. 

Comme avec Spring MVC, le support portlet met en oeuvre le taglib bind afin de remplir 
les champs du formulaire et d' africher les eventuelles erreurs de validation, comme dans 
le code suivant : 

<%@ page contentType="text/html " i sELIgnored="fal se" %> 

<%@ taglib prefix="c" uri="http://java. sun.com/jsp/jstl/core" %> 

<%@ taglib pref ix="fmt" uri="http://java. sun.com/jsp/jstl/fmt" %> 

<%@ taglib prefix="fn" uri="http://java. sun.com/jsp/jstl/functions" %> 

<%@ taglib prefix="spring" 

uri=" http://www.spri ngframework.org/tags" %> 

<%@ taglib pref ix="portl et" uri="http://java. sun.com/portlet" %> 

<form method="post" action="<portlet:actionURL> 

<portlet:param name="action" value="editTodoList"/> 
<portlet:param name="listld" value="${todolist.listId}"/> 
</portlet:actionURL>"> 

Id : <c:out value="${todolist.listId}"/Xbr/> 
Name : <spring:bind path="todolist.name"> 
<input type="text" name="name" 

val ue="<c:out val ue="${status .val ue}"/>" 

size="25" maxl ength="60"/> 
 <font color="red"> 

<c:out val ue="${status.errorMessage}"/X/font> 
</spring:bind> 

<br/Xbr/> 

<input type="submit" val ue="Save"/> 
</form> 



Conclusion 

Le support des portlets de Spring offre une solution innovante pour developper des 
applications de portail en offrant une implementation MVC. II permet 1' utilisation du 
conteneur leger au coeur de ce type d' application afin de gerer les controleurs relatifs 
aux portlets et de les relier aux composants des differentes couches (services metier et 
acces aux donnees). 

Pour selectionner le controleur a utiliser et gerer les vues, il reprend les concepts fonda- 
mentaux de Spring MVC. Cela favorise le decouplage des composants controleur et des 
composants de vue. De plus, il reutilise les mecanismes et entites de ce framework ainsi 
que sa facon de gerer les contextes applicatifs. 
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De ce fait, la prise en main du support par un developpeur connaissant Spring MVC et la 
technologie portlet est aisee. Spring offre d'ailleurs un support Web coherent grace a son 
framework MVC servlet, Spring Web Flow, et son support portlet. Les principes et meca- 
nismes mis en oeuvre ainsi que la gestion des contextes sont ainsi homogenes et coherents. 
Spring Web Flow offre egalement un support afin d'utiliser son moteur d'execution. 

Le tableau 10.1 recapitule les differentes entites du support portlet en les mettant en 
correspondance avec celles de Spring MVC. 



Tableau 10.1. Correspondance des entites du support portlet et de celles de Spring MVC 



Entite 


Spring MVC 


Support portlet 


Package de base 


org. springframework. web. servlet 


org. springframework. web. port let 


Controleur fagade 


Servl etDi spatcher 


PortletDispatcher 


Selection 
des controleurs 


HandlerMapping du package org.spring- 
f ramework. web. servl et 


HandlerMapping du package org. spring- 
framework. web. portlet 


Mappage de donnees 
dans des Beans 


Oui 


Oui 


Chalnage de 
HandlerMapping 


Non 


Oui 


Selection des vues 


ViewResolver du package org.spring- 
f ramework. web. servlet. view 


ViewResol ver du package org. spring- 
f ramework. web. servlet. view 


Chainage de 
ViewResolver 


Oui 


Oui 



Partie III 



Gestion des donnees 



La gestion des donnees couvre deux sujets : la persistance des donnees et la gestion 
des transactions. Nous etudions dans cette partie de quelle maniere stocker des 
donnees de maniere fiable et perenne, en particulier a l'aide d'une base de donnees 
relationnelle. 

Les deux chapitres qui la composent traitent des bases conceptuelles de chaque sujet et 
presentent les bonnes pratiques et le vocabulaire generalement utilises dans chaque 
domaine. Nous verrons ainsi ce qu'est le mappage objet/relationnel et ce que signifie 
une transaction ACID. 

Spring simplifie l'utilisation de ces deux domaines par rapport aux standards J2EE et 
permet d'avoir des applications mieux decoupees, plus simples et plus rapides a deve- 
lopper. Nous verrons en particulier l'utilisation d'Hibernate avec Spring, ainsi que 
celle de la POA afin de gerer les transactions de maniere transversale. 
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Persistance des donnees 



La persistance des donnees est generalement une problematique majeure pour les appli- 
cations J2EE, car les donnees manipulees par une application sont souvent d'une importance 
strategique. 

La principale technologie de persistance utilisee est celle des bases de donnees relation- 
nelles. Les rares solutions concurrentes, comme les bases de donnees orientees objet, 
sont peu utilisees, et nous ne nous attarderons pas sur elles. 

Les bases de donnees relationnelles permettent de traiter et de stacker de larges volumes 
de donnees, et ce d'une maniere totalement independante du langage de programmation 
utilise pour acceder a ces donnees (Java, PHP, C#, etc.)- Cette ouverture est une des 
raisons principales du succes de cette technologie. 

Cela a toutefois un prix pour le programmeur Java, puisque ce dernier est contraint de 
faire cohabiter deux mondes conceptuellement differents, le monde objet et le monde 
relationnel. En consequence, les applications Java s'appuyant sur des bases de donnees 
relationnelles sont tres souvent lourdes a coder, difficiles a faire evoluer et peu perfor- 
mantes. Cela provient essentiellement d'une utilisation abusive de JDBC (Java DataBase 
Connectivity), la technologie Java standard de bas niveau pour acceder aux bases de 
donnees. 

Ce chapitre commence par une introduction aux bonnes pratiques classiques en terme de 
persistance des donnees et introduit les concepts fondamentaux generalement admis dans 
ce domaine. 

Dans un deuxieme temps, nous etudions les principales solutions de mapping objet/rela- 
tionnel, ou ORM (Object Relational Mapping). Ces dernieres proposent une couche 
d' abstraction superieure a JDBC, sur laquelle elles reposent, et se proposent de combler 
le fosse entre bases de donnees relationnelles et objets Java. 
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Nous montrons ensuite de quelle maniere 1' integration de Spring avec ces technologies 
d'ORM repond au besoin de creer une couche de persistance a la fois simple a developper, 
performante et facile a faire evoluer. 

En fin de chapitre, nous illustrons a l'aide de notre etude de cas la facon d'obtenir la 
meilleure productivite possible en utilisant des outils et des frameworks qui otent au deve- 
loppeur le poids de la majorite des taches de bas niveau qu'il a traditionnellement a effectuer. 

Strategies et design patterns classiques 

La persistance des donnees est un sujet aujourd'hui relativement bien theorise. La plupart 
des entreprises utilisent des pratiques et un vocabulaire communs, rassembles sous forme 
de design patterns, ou modeles de conception. 

Nous allons commencer par presenter cette base commune, qui est un prerequis a la 
comprehension d'API de plus haut niveau, telles que la fameuse integration Spring/ 
Hibernate, que nous etudions en fin de chapitre. 

Le design pattern script de transaction 

Le design pattern script de transaction ( transaction script) correspond au developpement 
d'un code d'acces a la base de donnees par cas d'utilisation. Dans le domaine de la persis- 
tance, il s'agit du modele de conception le plus simple. On le retrouve souvent dans les 
applications non decoupees en couches, a l'interieur des servlets ou des actions Struts. 

Si Ton prend le cas de Struts, chaque action correspond a un cas d'utilisation. II y a done 
une relation 1-1 entre Taction Struts et le script de transaction. C'est pour cette raison 
que les applications qui utilisent ce modele de conception ne sont generalement pas 
concues en couches. Le code d'acces a la base de donnees est directement inclus dans 
Taction Struts, comme dans Texemple suivant : 

public class ManageTodosAction extends Di spatchAction { 

public final ActionForward render( 

ActionMapping mapping, ActionForm form, 
HttpServletRequest req, HttpServl etResponse res) { 

DynaActionForm manageTodosForm = (DynaActionForm) form; 
String listld = (String) manageTodosForm. get( "1 i stld" ) ; 

Connection conn = null; 
Statement stmt = null; 
Collection todos = new ArrayListO; 
try { 

conn = ConnectionHel per .getConnection( ) ; 

stmt = conn .createStatement( ) ; 

ResultSet rs = stmt.executeQueryC'SELECT * " + 

"FROM todo WHERE todo. todo_l i st_i d= ' " + 

listld + ; 
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while (rs.hasNext( )) ( 

Todo todo = new Todo( ) ; 

todo.setTodoId(rs.getString( "id") ) ; 

todo. setDescripti on (rs.getStringt "description" ) ) ; 

todos.add(todo); 

} 

req.setAttributet "todos" , todos) ; 
} catch (Exception e) { 

return mapping. f ind Forward ( "error" ) ; 
} finally { 

ConnectionHelper.closeConnection(stmt, conn) ; 

} 

return mapping. findForwardC'render") ; 

} 

Les points forts du pattern script de transaction sont les suivants : 

• Grande simplicite d'utilisation. 

• Les acces a la base de donnees peuvent etre optimises au maximum. 

• Plusieurs developpeurs peuvent travailler en parallele sur des cas d'utilisation differents, 
avec une gestion de projet tres simplifiee. 

Ses points faibles sont les suivants : 

• Aucune reutilisation du code : ce motif de conception s'essouffle rapidement des lors 
que l'application grandit un peu (plus de 10-15 tables en base de donnees). 

• La maintenance devient vite un cauchemar, chaque cas d'utilisation ayant ete deve- 
loppe de maniere procedurale. Changer une table de la base de donnees revient cher. 

En conclusion, ce motif de conception est utile dans certains cas specifiques, oil les acces 
en base de donnees doivent etre optimises au maximum. Cependant, fonder une applica- 
tion complete sur cette conception serait une erreur, car les cofits d' evolution et de main- 
tenance de l'application deviendraient rapidement eleves. 



Le design pattern DAO 

Les DAO (Data Access Object), ou objets d' acces aux donnees, ont la tache de creer 
(Create), recuperer (Retrieve), mettre a jour (Update) et effacer (Delete) des objets Java, 
d'ou l'expression associee pattern CRUD (Create, Retrieve, Update, Delete). 

Ce sont des classes utilitaires qui gerent la persistance des objets metier. Nous separons 
ainsi les donnees, stockees dans des JavaBeans, et le traitement de ces donnees. Les DAO 
ont generalement le squelette suivant : 

package tudu. domain. dao; 
import java.util .Collection; 
import tudu. domain. model .Todo; 
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/** DAO pour le JavaBean Todo */ 
public interface TodoDAO { 

/** Trouve tous les Todos appartenant a une liste. */ 
public Collection<Todo> getTodosByl_istId(String listld); 

/** trouve un Todo par son identifiant */ 
public Todo getTodo(String todold); 

/** Cree un Todo. */ 

public void createTodo(Todo todo); 

/** Met a jour un Todo. */ 

public void updateTodo(Todo todo); 

/** Efface un Todo */ 

public void removeTodo( String todold); 

} 

Un DAO est un objet threadsafe, c'est-a-dire qu'il est accessible en simultane par 
plusieurs threads. A l'inverse d'un JavaBean, qui contient des donnees specifiques de 
Taction en cours, un DAO ne fait que du traitement. II peut, par consequent, etre commun 
a plusieurs actions paralleles. Pour cette raison, les DAO peuvent etre implemented 
comme des singletons, avec une seule instance partagee par 1' ensemble des objets de 
1' application. 

Les points forts des DAO sont les suivants : 

• Reutilisation du code : un DAO peut etre utilise par plusieurs objets metier differents. 

• Simplicite : leur comprehension et leur bonne utilisation ne necessitent qu'un investis- 
sement leger. 

• Bonne structuration du code : separation de l'acces aux donnees du reste du code. 
Leurs points faibles sont les suivants : 

• lis sont potentiellement moins performants que du code SQL realise sur mesure pour 
chaque besoin metier. 

• lis sont longs et fastidieux a coder en JDBC. 



Le design pattern couche de domaine et le mappage objet/relationnel 

Le design pattern couche de domaine (domain layer) propose de modeliser le domaine 
fonctionnel avec des objets Java, d'ou son nom. II va done plus loin que le simple pattern 
DAO, car il apporte la volonte de modeliser un metier en langage informatique. II repre- 
sente une approche objet, que nous recommandons vivement pour les applications Web 
de moyenne ou grande taille. 
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L' etude de cas Tudu Lists est concue suivant ce principe. Le fonctionnel dicte qu'un utili- 
sateur possede plusieurs listes de todos et que chacune de ces listes possede a son tour 
plusieurs todos. Les JavaBeans User, TodoList et Todo (dans le package tudu. domain. model) 
ont ete concus en consequence. Ainsi, le JavaBean User possede en attribut une collection 
de TodoLi sts. II s'agit done bien d'une modelisation du domaine fonctionnel de l'application 
en Java. 

Bien entendu, il est primordial de pouvoir enregistrer ces objets en base de donnees. lis 
sont done sauvegardes dans des tables les representant. Le modele de donnees de Tudu 
Lists est explicite pour cela. L'objet User est sauvegarde dans une table User, possedant 
en champs les attributs du JavaBean. De la meme maniere, les relations entre les Java- 
Beans, qui sont des collections en Java, deviennent des cles etrangeres en base de 
donnees. 

La persistance de cette couche de domaine peut certes etre codee en JDBC pur, mais nous 
nous rendons vite compte des limitations de ce code artisanal des que nous voulons utili- 
ser des jointures complexes entre objets. C'est le cas, par exemple, des relations many-to- 
many, qui necessitent l'utilisation d'une table de jointure intermediate. Dans Tudu Lists, 
nous utilisons la table USER_T0D0_LIST pour effectuer la liaison entre les tables USER et 
T0D0„LIST. En effet, un utilisateur possede plusieurs listes, et une liste est possedee par 
plusieurs utilisateurs. Coder manuellement ce type de relation entre tables est fastidieux 
et peu efficace. 

Le mapping objet/relationnel, ou ORM (Object Relational Mapping), designe 1' ensemble 
des technologies permettant de faire correspondre un modele objet et une base de 
donnees relationnelle. Comme nous l'avons vu precedemment, cette correspondance est 
loin d'etre evidente. Par exemple, comment modeliser l'heritage ou le polymorphisme, 
deux notions objet qui n' existent pas du tout en base de donnees ? 

Ce concept de mapping objet/relationnel autorise done la realisation aisee d'une couche 
de domaine grace a l'utilisation d'outils specialises. C'est pour cette raison qu'il connait 
un succes grandissant depuis plusieurs annees. JDO, Hibernate ou les EJB Entite sont des 
exemples de technologies de mapping objet/relationnel populaires, que nous etudions 
ulterieurement dans ce chapitre. 

Les points forts du pattern couche de domaine sont les suivants : 

• Tres bonne evolutivite du code et couts de maintenance reduits. 

• La reutilisation du code est possible en de nombreux points de l'application. 
Ses points faibles sont les suivants : 

• Necessite de solides competences en programmation orientee objet et en gestion des 
transactions. 

• Pousse a l'utilisation d'un outillage evolue. 
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• Necessite une bonne comprehension du fonctionnement du moteur de mapping selec- 
tionne. 

• Fonctionne difhcilement sur un modele relationnel existant trop eloigne des concepts 
objets, par exemple, avec un schema de base de donnees denormalise. 

En conclusion, l'utilisation d'une couche de domaine devient necessaire des lors qu'une 
application depasse la taille critique de 10 a 15 tables en base de donnees. Le passage a 
cette etape necessite generalement de bonnes connaissances en technologie objet et un 
outillage adequat. Ces investissements necessaires sont rapidement rentabilises. 

En resume 

Les design patterns simples tels que le script de transaction et les DAO sont aujourd'hui 
largement repandus au sein des applications d'entreprise. II s'agit de concepts simples a 
mettre en oeuvre, mais qui doivent etre imperativement maitrises avant de se lancer dans 
la conception d'une application. 

L' apparition au cours des cinq dernieres annees de technologies de mapping objet/rela- 
tionnel efficaces et bon marche change la donne, puisqu'elles permettent de concevoir 
aisement des couches de domaine completes. 

Nous verrons dans la suite de ce chapitre comment ces technologies, couplees a Spring, 
reduisent considerablement le code d'une application, tout en ameliorant ses performances, 
sa maintenabilite et sa montee en charge. 

Les solutions d'ORM 

Historiquement, le marche de 1'ORM a vu le jour en 1994 avec l'apparition de TopLink, 
un framework alors revolutionnaire developpe par la societe The Object People (le 
« TOP » de TopLink). La plupart des solutions actuelles d'ORM sont directement issues 
de TopLink. A titre d'exemple, les fondateurs de Kodo JDO travaillaient avec TopLink il 
y a quelques annees. 

Au fil du temps, un grand nombre de solutions d'ORM sont apparues sur le marche, 
certaines standardisees (EJB, JDO), d'autres Open Source (Hibernate, OJB), dans un 
foisonnement creatif qui, au final, a plutot nui a leur adoption. 

Les sections qui suivent presentent les principales de ces solutions d'ORM et donnent les 
cles pour choisir la plus adaptee en fonction des besoins. 

Les EJB Entite 2.x 

Les EJB Entite sont, avec JDO, l'une des deux solutions d'ORM standardisees au sein de 
J2EE. Complexes, longs a developper, avec finalement peu de fonctionnalites, ils ont 
engendre beaucoup de deception au debut de leur utilisation. Le marketing originel a 
laisse un gout amer aux developpeurs et architectes qui s'etaient lances dans cette aventure 
au debut des annees 2000. 
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La version 2.x, aujourd'hui stable et performante, ainsi que l'outillage disponible, par 
exemple XDoclet, ont considerablement reduit ces problemes, au point d'en faire une 
excellente solution de persistance. Cette technologie continue cependant de souffrir 
d'une mauvaise reputation. 

Concepts et architecture 

Un EJB Entite est une forme de JavaBean qui est mappe sur une table. Chaque acces a cet 
objet, par le biais des methodes get( ) et sett ), par exemple, entraine une requete en base 
de donnees. 

Les EJB 2.x ne proposent qu'une solution de mapping rudimentaire. lis gerent la persis- 
tance des objets dans des tables, ainsi que les jointures one -to-many et many-to-many, 
mais ne vont pas beaucoup plus loin. lis sont suffisants dans la majorite des cas, leur prin- 
cipal atout etant leur simplicite d'utilisation. Pour les cas plus complexes, il est preferable de 
passer par JDBC. 

Le fait, par exemple, qu'ils ne soient pas dotes des concepts d'agregation, de projection, 
de requete imbriquee et de requete dynamique les rend inutilisables pour des applications 
de reporting. 

Au final, les EJB Entite 2.x sont des objets assez lourds a coder, a moins de disposer du 
bon outillage, qui ne resolvent que 80 % du probleme de la persistance. lis sont cepen- 
dant plus rapides a developper qu'une solution a base de JDBC classique et plus performants 
en production, du fait de l'utilisation frequente d'un cache en supplement. 

Le fait que les EJB Entite 2.x sont standardises leur offre un avantage evident. Dans la 
pratique, il faut cependant un travail assez consequent pour migrer une application d'un 
serveur d' applications a un autre, d'IBM WebSphere a BEA WebLogic, par exemple. 

Exemple d'utilisation simple 

Voici un exemple d' implementation simple de TodoDAO utilisant des EJB Entite 2.1 : 
package tudu. domain. dao.ejb; 

(...) 

public class TodoDaoJBoss implements TodoDAO { 

public Collection<Todo> getTodosByl_istId(String listld) ( 
try { 

Collection<TodoEjb> todoEjbs = TodoLltil 
.get Local Home( hfindBy List Id( list Id) ; 

Collection<Todo> todos = new ArrayListO; 
for (TodoEjb todoEjb : todoEjbs) { 
todos .add (todoEjb. getTodoVal ue( ) ) ; 

} 

return todos; 



Gestion des donnees 

Partie III 



catch (Exception e) { 
throw new DataRetrieval FailureException(e 
.getMessage( ) , e); 



public void createTodododo todo) { 
try { 

TodoEjb todoEjb = TodoLltil 

.getLocal Hornet ) .create(todo) ; 
} catch (Exception e) { 

throw new DataRetrieval FailureException(e 
.getMessaget ) , e); 

} 



(...) 

} 

Ce code souleve un certain nombre de problemes, notamment les suivants : 

• II n'est pas facile de retrouver l'EJB Entite TodoEjb a l'aide du contexte JNDI. c'est 
pourquoi ce code a ete externalise dans une classe d'utilitaire. 

• Les exceptions posent un probleme similaire a celles traitees en JDBC. N'etant pas des 
exceptions derivant de RuntimeException, elles forcent le developpeur a coder un grand 
nombre de try/catch au sein desquels il ne peut pas faire grand-chose d'autre que 
logger l'erreur et la renvoyer. 

• L'EJB TodoEjb recopie l'ensemble de ses champs dans le JavaBean Todo. En effet, 
utiliser un EJB directement serait dommageable en terme de performance puisque, a 
chaque appel a une methode get( ) ou set( ) de cet EJB, une requete equivalente en base 
de donnees est effectuee. II est preferable de recopier l'EJB dans un JavaBean dit value 
object (objet de valeur), me me si cette bonne pratique a pour inconvenient de faire 
ecrire un objet supplementaire et le code de recopiage. 

• La majeure partie du code metier, en particulier la recherche de Todos, n'est pas dans le 
DAO mais se trouve dans le fichier de configuration ejb-jar de l'EJB. Ce fichier est 
particulierement complexe et peut difficilement etre ecrit manuellement des que nous 
depassons la dizaine d'EJB Entite. Cette complexite ne peut etre resolue qu'imparfai- 
tement via l'une ou 1' autre des solutions suivantes : 

- Utilisation d'un IDE tel que WSAD d'IBM ou JBuilder Enterprise de Borland. Ces 
environnements sont toutefois couteux et lient forte ment le projet a un editeur. 

- Utilisation de XDoclet (http://xdoclet.sf.net), un generateur de code permettant de creer 
le fichier ejb-jar.xml. Le probleme de cette solution est que le developpement de 
XDoclet est quasiment stoppe, le focus des developpeurs etant aujourd'hui davan- 
tage sur Java 5 et les annotations. C'est done une solution que nous deconseillons pour 
cause de perennite non garantie. 
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EJB QL (Query Language) 

EJB Query Language est le langage de requete des EJB Entite. C'est grace a lui que le 
DAO precedent a pu executer la methode getTodosByLi stld( ). 

Melange de Java et de SQL, son apprentissage est tres rapide pour un developpeur ayant 
deja des competences dans ces deux langages. 

A titre d' illustration, voici le code EJB QL representant la methode getTodosByLi stld( ) : 

SELECT DISTINCT OBJECT(todo) 
FROM TodoEjb AS todo 
WHERE todo. list. id=?l 

Ce code EJB QL est inclus dans le fichier de configuration ejb-jar.xml et est valide lors 
du deploiement de 1' application, offrant ainsi une garantie de bon fonctionnement bien 
superieure a JDBC. 

Un grand nombre de fonctions lui font cependant defaut, notamment les suivantes : 

• II ne supporte pas les requetes dynamiques. 

• II ne propose que des fonctionnalites de requetage extremement limitees (pas de 
support des agregations, gestion trop simple des types Date, etc.). 

Les EJB 2.x sont-ils trop complexes ? 

Apres cette introduction, nous pouvons aisement conclure que l'utilisation des EJB 
Entite 2.x est lourde, sans pour autant apporter une solution de persistance complete. Si 
ce n'est done pas une solution recommandee, il convient de garder a l'esprit qu'elle reste 
la principale option si nous recherchons une solution de persistance standardised. En 
effet, JDO n'a pas vraiment decolle, et les EJB 3.0 sont encore tres jeunes. 

II faut done faire un choix entre la standardisation, le temps de developpement, la stabi- 
lity et la performance, et ce en fonction des priorites de chaque projet. 

Etat du marche 

II existe une multitude d'offres sur le marche des EJB 2.x. Aux cotes des grands acteurs 
commerciaux, tels que BEA, avec WebLogic, et IBM, avec WebSphere, quelques outsi- 
ders, comme IronFlare ou Caucho, et un petit nombre de serveurs Open Source (JBoss, 
Geronimo, Jonas), gagnent de plus en plus en popularite. 

Les EJB 2.x etant des composants complexes et longs a developper, l'avantage a long- 
temps ete dans le camp des grands acteurs commerciaux, qui etaient les seuls a proposer 
des environnements de developpement adaptes. Aujourd'hui, la donne a change, en parti- 
culier grace au generateur de code Java XDoclet et de XML. 

Les serveurs d' applications Open Source sont pour leur part arrives a un niveau de matu- 
rite suffisant pour pouvoir etre utilises pour les applications les plus critiques. II ne faut 
done pas craindre d'utiliser un serveur tel que JBoss en cluster pour des applications 
majeures. 
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Ajoutons que si de nombreuses entreprises choisissent d'utiliser en production un 
serveur d' applications commercial, elles laissent souvent leurs equipes developper avec 
des produits Open Source, qui sont moins couteux et plus agreables a utiliser en terme de 
rapidite, de debogage et de configuration. 



JDO (Java Data Object) 

JDO, le mecanisme standard de persistance transparente des objets Java, entre en partie 
en concurrence avec les EJB Entite mais s'en distingue par quatre points cles : 

• JDO n'est pas lie a un serveur d' applications J2EE. Les applications JDO sont par 
consequent plus facilement portables d'un serveur a un autre et sont meme utilisables 
dans des applications de type client lourd, sans aucun serveur d' applications. 

• JDO gere la persistance de JavaBeans simples, ou POJO (Plain Old Java Objects). Cela 
permet de creer des applications moins complexes et plus facilement testables. 

• JDO propose des fonctionnalites evoluees en terme de mapping objet/relationnel et de 
gestion des requetes. 

• JDO n'est pas limite aux bases de donnees relationnelles. II peut aussi bien enregistrer des 
objets sur d'autres types de supports, tels que bases de donnees objet, fichiers XML, etc. 

Malgre ses qualites indeniables, JDO n'a pas connu le succes a grande echelle. Les 
grands editeurs, comme IBM et BE A, ont principalement axe leur strategie sur les EJB. 
Quant au monde Open Source, il s'est focalise sur des solutions concurrentes, telles 
qu'Hibernate. Au final, JDO est reste confine a quelques petits editeurs commerciaux qui 
n'ont pas eu la puissance marketing necessaire pour faire decoller le marche. 

Concepts et architecture 

JDO propose une persistance transparente pour les JavaBeans. II suffit de coder des Java- 
Beans simples et d'utiliser un outil de mapping pour les faire correspondre aux tables 
d'une base de donnees. 

Par la suite, ces JavaBeans sont modifies (on parle d' instrumentation) par l'implementa- 
tion de JDO afin d'etre rendus persistants. Cette phase d' instrumentation a generalement 
lieu a la compilation, soit par generation de code Java a la volee, soit par modification des 
classes Java. Elle est entierement automatisee, si bien qu'en theorie le developpeur n'a 
pas a s'en preoccuper. 

L'utilisation du pattern DAO est toujours recommandee, en JDO comme en JDBC. JDO 
propose un objet unique, javax. jdo. PersistenceManager, pour rechercher et lire les Java- 
Beans sauvegardes. II s'utilise de la maniere suivante : 

PersistenceManager pm = pmFactory.getPersistenceManager (); 
Todo todo = (Todo) pm.getObjectByld (todold, false); 
TodoList todoList = todo.getTodoListt ) ; 

pm.currentTransactiont ) .begint ) ; 
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todoList.setNameCListe terminee") ; 

todo.setCompl etionDatet Calendar .get Instance ( ) . getTimet ) ) ; 
todo.setCompleted(true) ; 
pm.currentTransactiont ) .committ ) ; 

pm.cl ose( ) ; 

Dans cet exemple, l'objet pmFactory est de type javax. jdo.PersistenceManagerFactory. 
II s'obtient via une classe specifique de 1' implementation JDO utilisee. 

Nous retrouvons ici un fonctionnement proche de celui des EJB. Nous pouvons suivre les 
liens entre les objets, par exemple, todo.getTodoList( ), et les objets modifies sont auto- 
matiquement sauvegardes lors du commit de la transaction. 

JDOQL (JDO Query Language) 

A l'instar des EJB, JDO dispose de son propre langage de requete, le JDOQL (JDO 
Query Language), qui reste proche de Java et du SQL : 

SELECT FROM tudu. domain. model .Todo 
WHERE list. id == "1234" 
ORDER BY priority ASCENDING 

A la difference des EJB 2.x, ce code est utilise directement a l'interieur du code Java et 
n'est valide qu'a l'execution. 

JDO etant independant de la methode de persistance, ce langage reste plus proche de Java 
que du SQL, ce qui, dans la pratique, le rend legerement plus difficile a apprehender que 
ses concurrents. 

Utilisation dans un serveur d'applications J2EE 

Les solutions JDO sont normalement totalement independantes des serveurs d'applica- 
tions. Kodo JDO, par exemple, fonctionne de maniere identique avec WebSphere, 
WebLogic, JBoss, JRun, SunONE, etc. Cela ne veut pas dire que Kodo JDO soit totale- 
ment separe du serveur d'applications. II peut utiliser les pools de connexions JDBC du 
serveur, s'enroler dans des transactions JTA et, bien entendu, etre utilise par des servlets 
ou des EJB Session. 

Cette independance facilite la portability des applications d'un serveur a un autre. C'est la un 
avantage important si une application est destinee a etre vendue a de nombreux clients. 

Etat du marche 

Le marche de JDO est domine par quelques solutions commerciales : 

• Kodo JDO, achete fin 2005 par la societe BEA, qui est la solution la plus repandue et 
la plus robuste. C'est cette solution qu'utilise TheServerSide (http://www.theserverside.com), 
l'une des principales sources d'information dans le domaine J2EE. 

• LiDO, un produit plus confidentiel, mais qui a 1' avantage d'etre developpe par des 
Francais. 
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Les solutions Open Source, telles que JPOX, Triactive JDO ou Speedo, n'offrent clairement 
pas le meme niveau de service. 

JDO se rapproche des EJB dans leur version 3.0, puisque la specification de persistance 
des EJB 3.0 a ete faite conjointement. II est done possible d'utiliser les dernieres versions 
des outils JDO pour persister des EJB 3.0. 

Les solutions non standardises 

Outre les solutions standardises que sont les EJB et JDO, il existe une offre plethorique 
de solutions d'ORM non standardises . 

Generalement assez proches d'utilisation les unes des autres, les concepts a l'oeuvre etant 
toujours similaires, elles proposent des solutions de rechange souvent seduisantes aux 
standards presentes precedemment. 

TopLink 

TopLink est historiquement le premier produit d'ORM a etre apparu sur le marche. 
D'abord developpee en SmallTalk, cette solution a ete recodee en Java et appartient 
aujourd'hui a la societe Oracle. La plupart des autres frameworks s'inspirent des 
concepts de TopLink, qui reste une des references majeures du monde de la persis- 
tance. 

Repute pour sa robustesse, TopLink jouit de surcroit du soutien d'Oracle, qui lui garantit 
un support a long terme. II s'agit cependant d'une solution proprietaire, avec une API 
specifique. La choisir revient a se lier a long terme avec Oracle. 

Courant 2005, Oracle a fait prendre un tournant interessant a cette solution, en en faisant 
la base de son implementation des EJB 3.0. II s'agissait alors de la deuxieme implemen- 
tation presentee au grand public, juste apres celle de JBoss. II y a done chez Oracle une 
fusion en cours entre les technologies EJB, JDO et TopLink, ce qui devrait rendre cette 
solution tres attrayante a l'avenir. 

OJB (Object Relational Bridge) 

Projet de la fondation Apache, OJB (Object Relational Bridge) est un logiciel libre, qui 
possede sa propre API. A moyen terme, il devrait offrir une couche JDO complete. 

Pour l'heure, il patit de son manque de standardisation et de son positionnement trap 
proche d'Hibernate sur le marche des solutions Open Source d'ORM. 

iBATIS 

Encore un projet de la fondation Apache, iBATIS n'est pas une solution d'ORM a 
proprement parler. Cette technologie reste tres proche de la base de donnees et permet 
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d'utiliser des requetes ou des procedures stockees en Java a l'aide d'un fichier de 
mapping simple. II ne s'agit done pas de mapper des tables sur des objets. 

iBATIS possede des implementations en .NET et en Ruby, ce qui permet de reutiliser des 
mappings iBATIS dans des applications codees dans ces differents langages. 

Castor JDO 

Contrairement a ce que son nom laisse supposer, Castor JDO n'est pas une implementation 
du standard JDO que nous avons vu precedemment. 

C'est une solution de mapping Open Source relativement ancienne et populaire, qui se 
rencontre assez frequemment dans les applications d'entreprise francaises. Cela vient du 
fait que Castor a propose tres tot une solution Open Source de mapping Java/XML, ce 
qui a largement contribue a son succes. C'etait l'avantage du premier entrant, que Castor 
JDO n'a cependant pas reussi a maintenir aujourd'hui. 

Etat du marche 

Le marche de la persistance a ete florissant au cours des dix dernieres annees, qui ont vu 
naitre un tres grand nombre de solutions proprietaires et Open Source. Ces solutions se 
repandant en entreprise, nous arrivons a une periode de maturite, qui engendre des 
besoins de standardisation et de professionnalisation. 

Les solutions possedant des API proprietaires, comme TopLink ou OJB, sont amenees a 
se standardiser ou a disparaitre. 



Hibernate 

Hibernate est aujourd'hui une des solutions d'ORM les plus utilisees. Sa simplicite 
d' utilisation, sa gratuite et son excellente documentation, traduite qui plus est en 
plusieurs langues, dont le francais, l'ont fait retenir par de nombreuses equipes de deve- 
loppement. 

En particulier, Hibernate est la solution recommandee en interne dans plusieurs grandes 
SSII francaises, dans une optique de baisse des couts et d' amelioration de la qualite des 
developpements au forfait. 

Ce succes se retrouve dans le marche de l'emploi. A l'heure ou nous ecrivons ces lignes, 
le site monster.fr publie 85 offres d'emploi utilisant le mot-cle Hibernate, pour 4 offres 
JDO. A titre de comparaison, 93 offres d'emploi concernent le mot-cle Struts. 

Aujourd'hui, Hibernate est au cceur du nouveau standard EJB 3.0, dont Gavin King, le 
fondateur d'Hibernate, est l'un des createurs. 

Choisir Hibernate revient done a adopter une solution eprouvee, reconnue, peu onereuse 
et perenne. Qui plus est, l'engouement actuel pour cette technologie est un facteur favo- 
rable a la creation d'equipes dynamiques et motivees. 
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Concepts et architecture 

Hibernate est une solution classique, mappant des POJO, autrement dit des JavaBeans 
simples, sur les tables d'une base de donnees. Compare a d'autres solutions, ce mapping 
est particulierement avance. II permet, par exemple, d'utiliser aisement des fonctionnali- 
tes objet complexes, telles que l'heritage ou le polymorphisme, et d'utiliser des bases de 
donnees preexistantes avec des modeles de donnees complexes. 

Ce mapping entre les objets Java et la base de donnees est traditionnellement effectue a 
l'aide de fichiers XML de mapping, qui ont la forme suivante : 

<?xml version="1.0" encoding="UTF-8"?> 



<!D0CTYPE hibernate-mapping PUBLIC 

"-//Hibernate/Hibernate Mapping DTD 3.0//EN" 

"http:/ /hi bernate.sourcef orge.net/ hi bernate-mapping-3.0.dtd"> 



<hibernate-mapping> 

<class name="tudu. domain. model .Todo" 
tabl e="todo"> 



<cache usage="read-write" /> 



<id name="todoId" 
col umn="id" 

type="java.lang.String"> 

<generator class="uuid.hex"> 
</generator> 
</id> 



<property 

name="description" 

type="java.lang.String" 

update="true" 

insert="true" 

col umn="description"/> 



(...) 

<many-to-one 

name="todoList" 

class="tudu. domain. model .Todo List" 

cascade="none" 

outer-join="auto" 

update="true" 

insert="true" 

col umn="todo_l ist_id"/> 



<property 

name="compl eted" 
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type="boolean" 

update="true" 

insert="true" 

col umn="Compl eted"/> 

</cl ass> 
</hibernate-mapping> 

Ces documents XML de mapping sont relativement simples a ecrire a l'aide d'un editeur 
XML. Des outils plus evolues accroissent encore la productivity, notamment des outils 
graphiques, tels les Hibernate Tools disponibles sur le site d' Hibernate, des generateurs 
de code, comme XDoclet, ou plus recemment les annotations. 

Nous recommandons les deux bonnes pratiques suivantes : 

• Utiliser un editeur XML lorsque le nombre de tables est reduit (moins de 50) et le turn- 
over de l'equipe important. II est en effet couteux de reinstaller les outils et de former 
les developpeurs. 

• Investir dans une solution plus productive, Hibernate Tools en particulier, en cas de 
mapping long et complexe a realiser par un ou deux developpeurs experimentes. 

Une fois les JavaBeans mappes sur les tables de la base de donnees, Hibernate propose le 
mecanisme classique suivant pour utiliser le motif CRUD (Create, Retrieve, Update , 
Delete), tel que presente precedemment dans ce chapitre : 

public void saveTodo(String description, int priority) { 
Session session = HibernateLIti 1 .currentSession( ) ; 
Transaction tx = session. beginTransactiont ) ; 

Todo todo = new TodoO; 
todo.setDescript ion (description) ; 
todo. set Priority (priority) ; 
session. save(todo) ; 

tx. commit ( ) ; 

Hi bernateUti 1 . cl oseSessi on( ) ; 

} 

HQL (Hibernate Query Language) 

Pour des requetes plus complexes, Hibernate dispose de son propre langage de requete, le 
HQL (Hibernate Query Language), melange de Java et de SQL, dont voici un exemple : 

select user.todoLi sts 
from User user 
where user. userld=? 

Cette requete trouve toutes les listes de todos partagees pour un utilisateur donne. Remar- 
quons que, bien que nous travaillions ici directement avec les noms des objets Java 
(userld et non user_id), la syntaxe reste tres proche du SQL. 

De meme que le JDOQL, le HQL s' utilise directement dans le code Java. 
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Etat du marche 

Depuis 2004, Hibernate est engage dans la voie de la standardisation et de la profession- 
nalisation. L'embauche d'une partie de l'equipe d' Hibernate par le groupe JBoss, dont 
Gavin King, le fondateur du projet, a fortement influence cette professionnalisation, 
meme si des critiques se font jour sur le risque de mainmise du groupe JBoss sur le 
projet. 

Dans la pratique, nous constatons qu'Hibernate est utilise chez plusieurs operateurs de 
telecoms et grandes banques francaises et que cette solution semble largement employee 
au sein des applications d'entreprise. 

D'ici a cinq ans, il est possible qu'Hibernate soit completement remplacable par les EJB 
Entite version 3.0. Etant donne que la communaute Hibernate vient d' aider a redefinir en 
profondeur ce standard, une migration d' Hibernate vers des EJB Entite ne devrait pas 
constituer un probleme. 

Nous etudierons plus en detail l'utilisation d'Hibernate, en particulier avec Spring, dans 
P etude de cas de la fin du chapitre. 



Les EJB 3.0 

La version 3.0 des EJB incarne le triomphe de deux conceptions que nous defendons tout 
au long de cet ouvrage : 

• Les solutions de persistance fondees sur des POJO, telles qu'Hibernate, plutot que des 
solutions impliquant des objets complexes, a P image des EJB 2.x. 

• L'injection de dependances, telle que pratiquee dans Spring, afin d'ameliorer la testa- 
bility du code et de simplifier les appels entre EJB, sans passer par JNDI. 

Grace a l'utilisation intensive des annotations, une nouveaute du JDK 5.0, les EJB 3.0 ne 
sont plus que des JavaBeans simples. Ces annotations, qui viennent enrichir les classes et 
les methodes, permettent de definir, d'une part, la persistance et, d'autre part, les liens 
des JavaBeans entre eux (injection de dependances). 

Un certain nombre de nouvelles fonctionnalites de requetage viennent en outre combler 
le fosse existant entre les EJB 2.x et les solutions d'ORM concurrentes, notamment les 
requetes dynamiques et imbriquees. 

Comme il sera possible de deploy er des applications EJB 2.x sur des serveurs d' applica- 
tions a la norme EJB 3.0, il n'y a pas lieu de redouter des cofits de migration importants. 

Concepts et architecture 

Les EJB 3.0 permettent de coder des POJO persistants simplement et rapidement, 
reduisant d'autant les cofits de developpement. La configuration de ces POJO s'effec- 
tue par le biais d' annotations, et non plus d'un fichier XML monolithique, estime trop 
complexe. 
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Les concepts a l'oeuvre dans les EJB 3.0 sont finalement assez proches de ceux de 
TopLink, Hibernate ou JDO. 

Les EJB Entite 3.0 sont rendus persistants grace a l'objet javax. persistence. EntityMana- 
ger, qui permet l'utilisation des methodes CRUD classiques de la meme maniere que la 
session Hibernate. Voici de quelle maniere il peut etre utilise pour persister un objet : 

©Stateless 

public class TodoManagerSessionEJB implements TodoManagerSession { 
©Inject protected EntityManager entityManager; 
(...) 

public void createTodo(String description, int priority) ( 
Todo todo = new Todo( ) ; 
todo.setDescript ion (description) ; 
todo.setPriority(priority) ; 
entityManager. persist (todo) ; 

} 

(...) 

Nous constatons par cet exemple que les EJB 3.0 s'inscrivent dans la lignee des techno- 
logies de persistance etudiees precedemment et qu'ils seront facilement utilisables par 
les developpeurs ayant deja une experience d'Hibernate ou de JDO. L'utilisation des 
annotations (lignes commencant par @) et de 1' inversion de controle, que nous observons 
ici pour injecter l'objet enti tyManager, est aussi simple qu'intuitive, et elle devrait rapidement 
seduire. 

A titre indicatif, l'ancienne methode de recherche des EJB (JNDI) est toujours disponible 
pour trouver l'objet entityManager et necessite autant de code qu'auparavant : 

if (entityManager == null) ( 
try{ 

entityManager = (EntityManager) (new InitialContextO) 
. lookup ( "java :comp/ej b/ Enti tyManager" ) ; 
} catch (Exception e){}; 

} 

Voici un exemple d'EJB 3.0 simple, inspire de Tudu Lists : 
package tudu. domain. model .ejb3; 

import javax. persistence.*; 

©Entity 

@Table(name = "TODO" ) 

public class Todo implements java.io.Serializable { 

private String todold; 
private String description; 
private TodoList todoList; 
private int priority; 
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private boolean completed; 
private Date completionDate; 

publ ic Todo( ) { 



@Id(generate = GeneratorType.AUTO) 
public String getTodoIdO { 
return todold; 

} 

public void setTodoIdtstring todold) 
this.todoldd = todold: 



©Column (name = "DESCRIPTION" ) 
public String getDescription( ) { 
return description; 

} 

public void setDescription(String description) 
this. description = description; 



©ManyToOne 

@JoinColumn(name = "todo_l ist_id") 
public TodoList getTodoList( ) { 
return todoList; 



public void setTodoListdodoList todoList) { 
this. todoList = todoList; 

} 

(...) 
} 

Cet EJB inclut sa configuration sous la forme d' annotations et est des lors beaucoup plus 
simple a developper que son equivalent en EJB 2.x. L' utilisation du fichier de configura- 
tion ejb-jar.xml rendait en effet tres difficile l'ecriture d'un tel EJB en version 2.x si nous 
ne disposions pas d'un outillage approprie. En EJB 3.0, ce fichier a totalement disparu. 

De plus, remarquons que nous n'utilisons les annotations que lorsque la configuration 
par defaut n'est pas satisfaisante. Cette notion de configuration par exception permet de 
reduire davantage encore le nombre d'instructions necessaires pour developper un EJB 
complet. 
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Couts et risques 

Contrairement aux autres technologies presentees dans ce chapitre, les EJB 3.0 ne 
sont pas encore une solution reconnue et eprouvee a l'heure oil nous ecrivons ces 
lignes. II faudra sans doute quelque temps avant qu'elle soit utilisee massivement en 
production. 

Le passage aux EJB 3.0 induit des couts de formation peu importants pour les equipes 
maitrisant deja les EJB 2.x ou Hibernate. II s'agit en fait d'une evolution ou d'une 
amelioration, qui est attendue depuis longtemps par les developpeurs. Pour les deve- 
loppeurs debutants, les EJB 3.0 introduisent une simplification et une standardisation 
qui leur permettront d'etre productifs plus rapidement qu'avec les technologies 
concurrentes. Le passage aux EJB 3.0 semble quasiment toujours avantageux finan- 
cierement. 

Meme si cette technologie est recente, le passage aux EJB 3.0 se revele aisement maitri- 
sable et ne presente que peu de risque. II s'agit du socle technique standard J2EE, pour 
lequel existent deja plusieurs implementations. 

Etat du marche 

Les EJB 3.0 s'annoncent comme une solution de persistance standardised, supportee 
par les grands noms de l'industrie et prenant en compte les dernieres evolutions en 
matiere de mapping objet/relationnel, telles que la persistance transparente, l'inver- 
sion de controle et les annotations. Des 2005, des implementations exemples des 
EJB 3.0 ont ete fournies par JBoss et Oracle. II est clair que tous les grands acteurs du 
monde EJB (IBM, BEA) ou JDO vont rapidement fournir des implementations stables 
de ce standard. C'est done un marche jeune, mais extremement competitif, qui est en 
train de se former. 

L'avenir dira si les apports si prometteurs des EJB 3.0 ne seront pas gaches par des 
problemes dont les normes EJB 1.0 et JDO 1.0 avaient donne le penible exemple. Faute 
de pouvoir se mettre d' accord, les entreprises partenaires avaient alors defini des normes 
trop complexes, peu compatibles entre elles et trop peu pertinentes. 

En resume 

Nous venons d'etudier les principales solutions d'ORM du marche. Les EJB 2.x et 3.0, 
JDO et Hibernate en sont les principaux acteurs. Ces technologies restent assez proches 
dans leur utilisation et se sont engagees vers une standardisation commune. Dans 
l'avenir, nous pouvons done esperer pouvoir utiliser un socle technique robuste et 
mature, fonde sur la specification EJB 3.0. 

Cependant, cette perspective va necessiter encore quelques annees avant de se concre- 
tiser. L'architecte logiciel est done aujourd'hui contraint de bien connaitre les diffe- 
rentes solutions existantes afin de choisir la mieux adaptee au projet qu'il est en train 
de realiser. 
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Apports de Spring au monde de la persistance 

Spring reduit considerablement le nombre de lignes de code necessaires au developpe- 
ment des applications utilisant les principales technologies d'ORM du marche, que nous 
venons de passer en revue. 

En particulier, Spring propose une aide au developpement d' applications fondees sur les 
technologies d'ORM suivantes : 

• Hibernate 2.x et 3.0 

• iBATIS 

• JDO 

• OJB 

• TopLink 

Spring propose en outre une aide a 1' utilisation des EJB. Bien que cette aide ne soit pas 
centree sur la persistance, nous pouvons considerer que cette technologie est aussi 
couverte par Spring. 

Nous retrouvons ici les technologies etudiees precedemment, dont Spring aide 1' utilisation 
des quatre manieres differentes suivantes : 

• Spring facilite la creation d'une couche de DAO bien construite grace a 1' inversion de 
controle et a la separation en couches. 

• Spring simplifie et standardise l'utilisation de transactions dans la couche d'acces aux 
donnees. 

• Spring propose une hierarchie d'exceptions standardises, de maniere a avoir les 
memes exceptions dans les couches superieures, et ce quelle que soit la technologie de 
persistance utilisee. 

• Spring propose des classes d'utilitaires simplifiant considerablement le nombre de 
lignes de code a ecrire pour chacune de ces technologies. 

Si les deux premiers points ne portent pas specialement a debat, les deux suivants 
(gestion des exceptions et classes d'utilitaires) font generalement l'objet de discussions, 
car elles impliquent l'utilisation de classes propres a Spring. 

Un DAO heritant de la classe org. springframework.orm.hibernate3. support. Hi bernateDao- 
Support se lie en effet a Spring. C'est contraire a l'esprit initial d'utilisation d'un 
framework d' inversion de controle, cense permettre de ne pas dependre de ce framework 
et done de n'importer aucune de ses classes. 

Dans la pratique, nous pouvons utiliser Spring soit comme un simple moteur d' inversion 
de controle, soit comme un framework complet facilitant 1' integration de differentes 
technologies. La plupart des projets optent pour la deuxieme option et choisissent d'utili- 
ser Spring a son maximum. C'est ce que nous allons faire dans l'etude de cas Tudu Lists. 
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Tudu Lists : persistance des donnees 

Nous avons choisi de developper Tudu Lists avec Hibernate, car ce framework beneficie 
d'une tres bonne integration avec Spring. 

Cependant, Spring supportant de maniere relativement similaire les differentes technolo- 
gies d'ORM que nous avons etudiees, ce cas pratique reste pertinent, meme si vous choisissez 
d'utiliser une autre solution qu' Hibernate. 

Nous avons fait le choix de tirer le meilleur parti des capacites de Spring en l'utilisant 
tout a la fois pour simplifier le code de persistance et gerer les transactions et les 
exceptions. 

Creation des fichiers de mapping XML 

Dans notre chaine de construction de code, nous creons les fichiers de mapping Hiber- 
nate manuellement, de facon a ne pas dependre d'outils trop complexes a mettre en 
oeuvre. 

Nous recommandons simplement l'utilisation de l'editeur XML Web Tools Platform, qui 
ajoute un support XML de bon niveau a Eclipse. 

Les fichiers de mapping utilises n'ont rien de particulier. Pour le lecteur qui souhaiterait les 
etudier, nous conseillons la lecture de la documentation en ligne d'Hibernate, recemment 
traduite en Francais, a l'adresse http://www.hibernate.org/hib_docs/reference/fr/html/. 

Nous pourrions aussi choisir d'integrer XDoclet, Hibernate et Ant afin d' avoir un envi- 
ronnement de travail plus productif. Si ces choix permettent de generer tres rapidement 
des fichiers de configuration et done de demarrer un projet sans delai, ils obligent toute- 
fois a utiliser le JDK 1 .4 et Hibernate 2.x, car le developpement de XDoclet semble avoir 
ete stoppe depuis l'arrivee des annotations (JDK 5.0). 

Creation des POJO 

Nous codons nos POJO en Java a l'aide d'Eclipse. Dans la mesure oil ces POJO repre- 
sented le domaine fonctionnel de 1' application, une analyse doit d'abord etre menee afin 
de specifier de quels objets nous avons besoin et selon quelles liaisons. 

Le codage de ces POJO en Java est particulierement rapide, d'autant plus qu' Eclipse 
permet de generer automatiquement les methodes get() et set(). II suffit d'ecrire les 
champs prives correspondant aux attributs de chaque objet puis de selectionner dans le 
menu Source la fonction Generate Getters and Setters. 

Au final, nos POJO sont de la forme suivante : 

package tudu. domain. model ; 

import java.io.Serializable; 
import java.util .Date; 
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/** 

* Un Todo. 

*/ 

public class Todo implements Serializable, Comparable { 

private String todold; 

private TodoList todoList; 

private Date creationDate; 

private String description; 

private int priority; 

private boolean completed; 

private Date completionDate; 

private Date dueDate; 

public String getTodoIdO { 
return todold; 

} 

public void setTodoIdtString todold) { 
this. todold = todold; 

} 

public boolean isCompletedO ( 
return completed; 

} 

public void setCompleted(boolean completed) { 
this. completed = completed; 

} 

public Date getCompletionDateO ( 
return completionDate; 

} 

public void setCompletionDatetDate completionDate) { 
this. completionDate = completionDate; 

} 

( ... ) 



public TodoList getTodoLi st( ) { 
return todoList; 

} 
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public void setTodol_ist(Todol_ist todoList) { 
this.todoList = todoList; 

} 

public int compareTot Object o) { 
Todo that = (Todo) o; 

int order = that.getPriority( ) - this.getPriorityt ) ; 
if (thi s . i sCompl eted( ) ) { 
order += 10000; 

} 

if (that.isCompletedO) { 
order -= 10000; 

} 

if (order == 0) { 

order = (this.getDescription( ) + this.getTodoId( ) ) .compareTo(that 
.getDescription( ) 
+ that.getTodoIdO); 

} 

return order; 

} 

public boolean equal s(0bject o) { 
if (this == o) { 
return true; 

} 

if (!(o instanceof Todo)) { 
return false; 

} 

final Todo that = (Todo) o; 

if (todold != null ? Itodold. equal s(that. todold) : that.todold != null) { 
return false; 

} 

return true; 

} 

public int hashCodeO { 

return (todold != null ? todold. hashCode( ) : 0); 

} 

} 

Les todos devant pouvoir etre tries automatiquement par priorite et date, le JavaBean Todo 
doit implementer l'interface Comparable, qui force l'ecriture de la methode compareTo. 
C'est a l'interieur de cette methode qu'est inscrite la logique permettant de trier les todos 
dans le bon ordre. 
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Notons egalement que les todos etant des objets Java standards, les methodes equal s( ) et 
hashcodet ) doivent etre correctement implementees. Dans ce cas precis, cela reste relati- 
vement simple, car les todos sont simplement identifies par leur attribut todold. 

Implementation des DAO 

Pour une bonne separation des couches, une pratique encouragee par l'utilisation de 
Spring, nous creons des interfaces pour chacun de nos DAO. 

Parmi les multiples avantages de ces interfaces, citons notamment les suivants : 

• Specification, lors de la phase de conception, des appels a la base de donnees qui 
seront utiles. 

• Etablissement d'un contrat entre les developpeurs de la couche de persistance et ceux 
des couches superieures. 

• Augmentation de la testability de 1' application (voir le chapitre 17). 

• Meilleure migration future vers un autre systeme de persistance ou une version supe- 
rieure de l'outil en cours. 

II est important d'utiliser Eclipse ou un IDE comparable ann de generer automatiquement 
une implementation a partir d'une interface. Cela rend presque nul le cofit supplemen- 
tal induit par le developpement des interfaces. 

Nous avons vu, lors de la presentation d' Hibernate, que l'ecriture du DAO Hibernate 
necessitait l'ouverture d'une session Hibernate et d'une transaction, puis leur fermeture. 

Voici maintenant un DAO code en utilisant Spring : 

package tudu.domain.dao.hibernate3; 

import org. spring-framework. orm. hi bernate3. support. Hi bernateDaoSupport; 
(...) 

public class TodoDAOHibernate extends HibernateDaoSupport implements TodoDAO { 
/** 

* Trouve un Todo par son identifiant. 

*/ 

public Todo getTodo(String todold) { 
return (Todo) getHibernateTemplatet ) 
.get(Todo. class, todold); 

} 

/** 

* Sauvegarde un Todo. 
*/ 
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public void saveTodotTodo todo) { 

getHibernateTempl ate( ) .saveOrUpdate(todo) ; 

} 

/** 

* Efface un Todo. 
*/ 

public void removeTodo(String todold) { 

getHibernateTempl ate( ) . del ete(getTodo( todold) ) ; 

} 

} 

La premiere chose que nous remarquons dans ce code est son extreme concision. II suffit 
pour s'en convaincre de le comparer au design pattern script de transaction, ecrit en 
JDBC en debut de chapitre. Par rapport a du code Hibernate standard, nous n'avons pas 
eu a coder les ouvertures et les fermetures de session ni la gestion des transactions. 

II existe cependant encore du code superflu ici, la methode saveTodo n'etant pas utile. 
L'un des atouts d'Hibernate est de permettre de sauvegarder automatiquement un ensem- 
ble complet d'objets. Dans Tudu Lists, la creation d'un objet Todo revient a ajouter un 
nouveau todo dans une liste : 

TodoList todoList = todoLi stsManager .f indTodoListd istld) ; 
todoList.getTodos( ) .add (todo) ; 
| todo.setTodoList(todoList) ; 

Lensemble de ce code fait partie d'une transaction geree par Spring. Lors du commit de 
cette transaction, la liste todoList est sauvegardee, ce qui entraine automatiquement la 
sauvegarde du nouvel objet Todo, qui en fait desormais partie. 



Utilisation d'HibernateDAOSupport 

Les DAO utilises dans Tudu Lists heritent tous de org. springframework.orm. hiber- 
nates, support. Hi bernateDaoSupport, une classe donnant acces a Hi bernateTempl ate. Cette 
derniere permet de reduire considerablement le code a ecrire pour utiliser Hibernate. 
Nous ne pouvons que conseiller une lecture attentive de la javadoc de cette classe, qui 
reprend les methodes d'Hibernate pour sauvegarder, mettre a jour, effacer, etc. 

Tudu Lists fournit un exemple d'utilisation de l'ensemble des methodes couramment 
necessaires lors de la persistance d'un objet ou d'une collection d'objets. 

A nouveau, l'heritage de cette classe lie fortement l'application en cours au framework 
Spring, ce qui n'est pas recommande par l'equipe developpant Hibernate. II est bien 
entendu toujours possible d'utiliser Hibernate de maniere traditionnelle, c'est-a-dire sans 
heriter de cette classe, et de continuer d'utiliser Spring uniquement pour gerer l'inversion 
de controle et les transactions. 

Cependant, nous considerons que les avantages de cette classe sont bien superieurs a ses 
inconvenients, tant elle offre un gain de temps et une simplification du code appreciables. 
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De plus, si nous devions cesser de l'utiliser, un refactoring de la couche de persistance 
serait simple et sans risque, grace au bon decoupage de 1' application. 

Configuration de Spring 

La configuration de Spring pour la couche de persistance est stockee dans le fichier 
WEB-INF/applicationContext-hibernate.xml. 

II s'agit d'un fichier de configuration Spring standard, qui cree les differentes implemen- 
tations des DAO sous la forme de Beans Spring, en les liant (par inversion de controle) 
avec la SessionFactory d'Hibernate et un gestionnaire de transactions : 



<bean id="sessionFactory" 
class="org.springf ramework.orm.hibernate3. Local Session Factory Bean "> 

<property name="conf ig Location "> 

<value>classpath:hibernate.cfg.xml</val ue> 
</property> 
</bean> 

<bean id="transactionManager" 
class="org.springf ramework.orm.hibernate3.HibernateTransactionManager"> 
<property name=" session Factory "> 
<ref bean="sessionFactory" /> 
</property> 



<bean id="userDAO" 

class="tudu.domain.dao.hibernate3.llserDA0Hibernate"> 
<property name=" session Factory "> 
<ref bean="sessionFactory" /> 
</property> 
</bean> 

<bean id="roleDA0" 

class="tudu.domain.dao.hibernate3.RoleDA0Hibernate"> 
<property name=" session Factory "> 
<ref bean="sessionFactory" /> 
</property> 
</bean> 

<bean id="todoLi stDAO" 

class="tudu.domain.dao.hibernate3.TodoListDA0Hibernate"> 
<property name=" session Factory "> 
<ref bean="sessionFactory" /> 




<?xml version="1.0" encoding="UTF-8"?> 
<!D0CTYPE beans PUBLIC "-//SPRING/ /DTD BEAN// EN " 

"http://www.springframework.org/dtd/spring-beans.dtd"> 



<beans> 



</bean> 
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</property> 
</bean> 

( ... ) 
</beans> 

La seule configuration importante a ce stade consiste a donner une session Hibernate a 
chaque DAO Hibernate. 

Les transactions sont quant a elles gerees dans la couche superieure, qui est capable 
d'orchestrer l'utilisation conjointe de plusieurs JavaBeans. Nous avons ainsi des transactions 
qui peuvent porter sur plusieurs DAO. 

Voici un exemple tire du fichier WEB-INF/applicationContext.xml (cette configuration 
est detaillee au chapitre 12, dedie aux transactions) : 

<bean id="userManagerTarget" 

cl ass="tudu. service. impl .UserManagerlmpl "> 
<property name="userDAO"> 
<ref bean="userDAO" /> 
</property> 

<property name="rol eDA0"> 
<ref bean="roleDAO" /> 
</property> 

<property name="todoLi stDA0"> 
<ref bean="todoListDAO" /> 
</property> 

<property name="todoDAO"> 
<ref bean="todoDAO" /> 
</property> 

<property name="propertyDAO"> 
<ref bean="propertyDAO" /> 
</property> 
</bean> 

<bean id="userManager" 

cl as s=" org. spring-framework, transact ion. interceptor. Transact ionProxy Factory Bean" > 
<property name="transactionManager"> 
<ref bean="transactionManager" /> 
</property> 

<property name="target"> 

<ref local="userManagerTarget" /> 
</property> 

<property name="transactionAttributes"> 
<props> 

<prop key=" create*" >PROPAGATION_REQU I RED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="delete*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 
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Utilisation du pattern session-in-view 

Le design pattern session-in-view est particulierement important si nous voulons utiliser 
Hibernate de maniere simple et performante. Cependant, son apparente complexite et son 
utilisation particuliere necessitent une explication plus detaillee. 

L'idee sur laquelle repose ce pattern est d'associer une session Hibernate au fil d'execution, 
ou thread, de la requete HTTP en cours. Cela presente les deux avantages suivants : 

• L'ouverture d'une seule session Hibernate apporte un leger gain de performance. 

• La session Hibernate est accessible a partir de n'importe quel endroit de 1' application. 

Cette derniere assertion prete toutefois a confusion. Si 1' application est decoupee en 
couches avec Spring, n'est-ce pas precisement pour eviter d' avoir des acces a la couche 
de persistance depuis n'importe oil ? 

En realite, l'acces a la session Hibernate n'est utile que pour une seule raison : l'utilisa- 
tion maximale des fonctionnalites de lazy-loading, ou initialisation tardive, d'Hibernate. 
En effet, afin de limiter le nombre et la taille des requetes effectuees en base de donnees, 
Hibernate ne va pas toujours chercher l'integralite des donnees reclamees et ne charge les 
jointures que lorsqu'elles sont directement demandees par 1' application. Optionnel dans 
Hibernate 2.x, ce fonctionnement est devenu le mode par defaut d'Hibernate 3.0, car il 
ameliore nettement les performances. 

Voici comment fonctionne le retrait d'une jointure classique one-to-many dans un exemple 
fictif emprunte a Tudu Lists : 

1. Couche de persistance : recherche d'un objet TodoList, qui represente une collection 
de todos. 

2. Une requete en base est executee sur la table T0D0_LIST, mais pas sur la table TODO. 

3. Cet objet TodoLi st est remonte jusqu'a la couche Struts, qui le stocke en tant qu'attribut 
de la requete HTTP. 

4. L' action Struts renvoie vers une page JSP. 

5. Dans la JSP, une bibliotheque de tags prend l'objet TodoLi st et itere sur la collection 
de todos qu'il possede. 

6. Au moment de cette iteration, Hibernate execute une nouvelle requete SQL sur la 
table TODO arm de recuperer les informations concernant les todos. 

Le lazy-loading designe ainsi le fait de ne charger qu'au dernier moment les informations 
provenant de la base de donnees. 

Ce principe permet de reduire les acces a la base de donnees. Nous n'avons generalement 
pas besoin d'un graphe d'objets complet, mais juste de quelques objets. II est done tres 
fortement recommande. 
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Malheureusement, pour utiliser ce precede efficacement, il est necessaire d' avoir acces a 
la session Hibernate a partir de n'importe quelle partie de 1' application, y compris, 
comme dans notre exemple, des JSP. 

C'est ce que propose de faire le pattern session-in-view en stockant la session Hibernate 
dans la thread en cours (nous ne detaillons pas ici son implementation, qui necessite une 
connaissance de l'objet ThreadLocal). 

Spring propose pour cela un filtre de servlet pret a l'emploi, qui s'insere dans le fichier 
WEB-INF/web.xml de la maniere suivante : 

<filter> 

<filter-name>Hibernate Session In View Filter</filter-name> 
<f i 1 ter-cl ass> 

org.springframework.orm.hibernate3.support.0penSessionInViewFilter 

</filter-class> 
</filter> 

( ... ) 

<filter-mapping> 

<filter-name>Hibernate Session In View Filter</filter-name> 

<url -pattern>*.action</url -pattern> 
</filter-mapping> 

<filter-mapping> 

<filter-name>Hibernate Session 

<url -pattern>/secure/dwr/*</url 
</filter-mapping> 

<filter-mapping> 

<filter-name>Hibernate Session In View Filter</filter-name> 

<url -pattern>/j_acegi_security_check</url -pattern> 
</filter-mapping> 

Ce mapping est utilise a trois endroits differents : 

• Actions Struts. 

• DWR, le framework utilise pour les fonctionnalites AJAX de 1' application : les POJO 
qui utilisent le lazy-loading sont en effet presentes en JavaScript. Nous etudions cette 
partie plus au chapitre 9, dedie a AJAX. 

• Phase de login, Acegi Security utilisant bien entendu les POJO User et Rol e pour gerer 
l'authentification et les autorisations. 

Ann de tester l'utilisation du pattern session-in-view, nous proposons d'enlever certains 
de ces mappings et d'observer les erreurs qui ne manqueront pas de se produire dans 
1' application. 



In View Filter</filter-name> 
-pattern> 
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Utilisation du cache d'Hibernate 

Pour obtenir de bonnes performances, l'utilisation d'un cache conjointement avec Hiber- 
nate est essentielle. Pour ce faire, Hibernate s'integre a un certain nombre de solutions de 
cache, dont nous ne retenons pour notre demonstration que deux solutions : 

• JBoss Cache. Solution complete offrant un cache transactionnel en cluster. II est 
recommande de ne l'utiliser que si nous avons besoin d'un cache en cluster, une option 
generalement inutile, etant donne les performances deja tres elevees d'Hibernate. 

• Ehcache. Ce cache tres simple d'utilisation et tres performant est la solution de cache 
la plus utilisee avec Hibernate. 

C'est Ehcache que nous avons choisi d'utiliser avec Tudu Lists. Sa configuration est definie 
dans le fichier JavaSource/ehcache.xml : 

<ehcache> 
( ... ) 

<cache name="tudu. domain. model .Todo" 
maxElementsInMemory="50000" 
eternal ="fal se" 
overf 1 owToDisk="true" 
timeToIdleSeconds="600" 
/> 

<cache name="tudu. domain. model .TodoList" 
maxElementsInMemory="20000" 
eternal ="fal se" 
overf 1 owToDisk="true" 
timeToIdleSeconds="600" 
/> 

( ... ) 
</ehcache> 

Chaque POJO et collection de POJO enregistrables doivent etre dermis dans ce fichier de 
configuration, qui comporte les elements de configuration suivants : 

• maxInMemory : nombre maximal d'objets dans le cache en memoire. 

• eternal : precise si les objets vivent eternellement dans le cache. 

• timeToIdl eSeconds : temps de vie des objets, lorsqu'ils ne sont pas utilises. 

• timeToLiveSeconds : temps de vie des objets. 

• overflowToDisk : precise si les objets peuvent etre sauvegardes sur le disque lorsqu'il 
n'y a plus de place en memoire. 

Dans l'exemple ci-dessus, les todos peuvent etre 50 000 en memoire avant d'etre sauve- 
gardes sur le disque dur et ne vivent pas plus de dix minutes. 

Cette configuration est bien entendu entierement dependante des besoins fonctionnels. 
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Conclusion 

A l'heure actuelle, 1' utilisation directe de JDBC est surpassee par celles des frameworks 
d'ORM, que ce soit en terme de qualite, de productivite ou de performance. 

Ces frameworks ne necessitent pas pour autant des competences moindres en matiere de 
base de donnees. Bien au contraire, pour les utiliser efficacement, les developpeurs 
doivent etre parfaitement a l'aise avec les mondes objet aussi bien que relationnel. Cela 
induit des cofits supplementaires de formation et de recrutement, qui ne sont rentabilises 
qu'a moyen terme. 

Par ailleurs, la profusion actuelle de solutions d'ORM peut preter a confusion. Une vue 
d'ensemble de ces differentes solutions est necessaire pour choisir la mieux adaptee a un 
projet precis. 

Nous ne saurions trop insister sur l'extreme productivite du couple Spring-Hibernate. 
II est interessant de constater que cette productivite ne joue pas au detriment de la qualite, 
puisque l'application finale est proprement decoupee en couches, ni de la performance, 
Hibernate generant des requetes optimisees et disposant de caches performants. 
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Pour stacker des donnees et echanger des messages, les applications d'entreprise mettent 
en jeu de nombreuses ressources, telles que bases de donnees, serveurs de messagerie 
applicative, gros systemes, etc. Ces applications doivent maintenir une coherence entre 
ces differentes ressources afin de garantir la consistance des donnees en cas d'annulation 
de traitement, d'erreur, de bogue ou de panne. Au coeur des technologies Java/J2EE, le 
concept de transaction vise a resoudre ces problematiques de coherence. 

Ce chapitre passe en revue les principales notions inherentes aux transactions et explique 
comment le framework Spring permet de les mettre en oeuvre de maniere optimale dans 
une architecture, et ce, quels que soient les technologies ou frameworks sous-jacents 
employes. 

Rappels sur les transactions 

Oublier de gerer les transactions dans une application n'engendre pas necessairement de 
dysfonctionnements visibles. Cependant, cet oubli ne permettant pas de garantir la 
consistance des donnees manipulees, des erreurs dedicates a detecter peuvent survenir. 
Ces erreurs sont souvent difficilement reproductibles sans donnees de production et peuvent 
impacter tous les systemes d'information utilises par l'application. Par exemple, les 
donnees relatives a un client n'ont pas ete correctement enregistrees dans les differentes 
sources de donnees de l'entreprise ; de ce fait, des donnees erronees concernant ce client 
se retrouvent dans certaines applications tierces. 

La notion de transaction est done primordiale. Elle doit etre mise en oeuvre dans toute 
application realisant des mises a jour dans des sources de donnees. 
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Proprietes des transactions 

Prenons un exemple concret tire de notre etude de cas Tudu Lists. L'importation d'une 
liste de todos en mode modification est particulierement appropriee, puisqu'il s'agit de 
fusionner les valeurs des elements de la nouvelle liste avec les valeurs de l'ancienne. 

Imaginons que ce traitement echoue a sa moitie. Les donnees de la liste ne sont des lors 
pas homogenes. La premiere partie correspond a des donnees de la nouvelle liste, et la 
seconde a des donnees de l'ancienne. Ces dernieres donnees n'ont pas ete modifiees 
puisque l'execution s'est arretee avant leur traitement. 

Les transactions permettent de pallier ce probleme, un de leurs objectifs etant d' assurer 
1' atomicite d'un traitement. Si une erreur se produit dans l'importation, les modifications 
ne sont pas repercutees en base, et les donnees de la liste restent dans leur etat initial. Par 
contre, la liste est effectivement modifiee en base si le traitement se deroule correctement 
jusqu'a son terme. 

Le role des transactions est done de valider les modifications realisees par des traitements 
d'une methode si aucune erreur ne se produit et de les annuler dans le cas contraire. De 
cette maniere, les donnees restent coherentes. Ajoutons qu'une fois les modifications sur 
les donnees validees, celles-ci doivent etre durables. 

L'exemple precedent montre qu'une transaction doit etre une unite de traitements (unit of 
work). De la sorte, toutes les modifications realisees par ces traitements doivent etre validees 
ou annulees en meme temps. 

Une transaction doit en outre verifier les proprietes fondamentales suivantes, commu- 
nement designees sous l'acronyme ACID (atomicite, consistance, isolation, durabilite) : 

• Atomicite. Tous les traitements realises dans une transaction sont vus par 1' application 
comme une seule unite et sont done indivisibles. 

• Consistance. Les donnees des differents systemes ne peuvent rester dans des etats 
incoherents. Ces etats sont, par exemple, des transitions necessaires au cours des diffe- 
rents traitements de la transaction, ces derniers pouvant n'etre pas visibles au moment 
de son achevement. 

• Isolation. Definit la visibilite des etats internes de la transaction par le reste de 1' appli- 
cation au cours de sa realisation. Suivant les sources de donnees et les technologies 
utilisees, l'isolation peut avoir plusieurs niveaux. 

• Durabilite. Lorsqu'une transaction est validee, les modifications realisees sur les 
differentes donnees sont definitives et entierement visibles par le reste des applications 
qui utilisent la source de donnees. 

Granularite des transactions 

Les transactions peuvent avoir plusieurs niveaux de granularite trans actionnelle, allant 
des transactions simples aux transactions imbriquees : 

• Transactions simples. En vertu des proprietes ACID, une transaction simple est un 
bloc indivisible, qui possede done une granularite importante. Elle correspond a une 
boite noire contenant les differents traitements. 
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• Transactions imbriquees. Pour les systemes compatibles, il est possible de realiser 
des transactions imbriquees, a la granularite plus fine. Elles consistent en des sous- 
blocs transactionnels au sein d'une meme transaction. Ces blocs peuvent etre annules 
independamment de la transaction ou valides en meme temps que cette derniere. 



Isolation transactionnelle 

Certains systemes d'information autorisent differents niveaux d'isolation afin de permet- 
tre aux applications de maitriser completement les donnees visibles a l'exterieur de la 
transaction. Les applications peuvent de la sorte jouer indirectement sur les performances 
d'acces aux donnees puisque cette propriete s'appuie generalement sur des mecanismes 
de gestion de la concourance d'acces et de verrous. 

Les bases de donnees relationnelles sont un exemple classique de systeme d'information 
utilisant ce mecanisme. Ces bases de donnees fournissent plusieurs niveaux d'isolation 
des donnees lors de leur manipulation au cours d'une transaction, qui ne correspondent 
pas tous a une isolation stride des donnees et peuvent done entrainer des problemes, 
comme le recapitule le tableau 12.1. 



Tableau 12.1. Typologie des problemes induits par les transactions 



Type de probleme 

Dirty Read (lecture sale) 



Non-Repeatable Read 
(lecture non reproductible) 



Phantom Read 
(lecture fantome) 



Description 

Un fil d'execution voit des donnees d'une transaction sans que celle-ci soit terminee. De ce 
fait, les donnees se trouvent dans un etat transitoire au moment de la lecture. L'utilisation et la 
manipulation des valeurs de ces donnees peuvent entrainer des incoherences au niveau des 
donnees. 

Pour notre exemple, tire de I'etude de cas, une autre transaction peut voir les valeurs interme- 
diaires lors du rafralchissement d'une liste de todos. Cela signifie que certaines valeurs cor- 
respondent a I'ancienne liste non rafrafchie et d'autres a la nouvelle rafralchie. La liste n'est 
done pas coherente dans sa globalite. 

Une lecture recupere des donnees dans un certain etat dans la transaction. Si une application 
modifie ces donnees parallelement, la meme lecture renvoie ces donnees modifiees. La tran- 
saction n'est done pas completement isolee vis-a-vis des donnees modifiees par les autres 
transactions. De ce fait, les lectures ne sont pas reproductibles. 

Le cas se produit si une transaction travaille sur un todo qui est modifie par une autre transac- 
tion de maniere concourante dans le cadre d'une importation d'une liste de todos. Cette modi- 
fication est repercutee avant la fin de la premiere transaction, et I'enregistrement n'a pas la 
meme valeur tout au long de I'autre transaction. 

Contrairement aux lectures non reproductibles, qui impliquent une modification des donnees, 
les lectures fantomes sont la consequence d'insertions ou de suppressions de donnees entre 
leur lecture et leur utilisation. 

Le cas se produit si une transaction travaille sur un todo qui est supprime par une autre 
transaction de maniere concourante dans le cadre de I'importation d'une liste de todos. Cette 
suppression est repercutee avant la fin de la premiere transaction, et I'enregistrement n'existe 
plus dans I'autre. 



II est important de bien cerner les problemes eventuels pour chaque niveau d'isolation et 
de positionner ces niveaux avec precaution. Ces problemes etant tous issus d'acces 
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concourants aux donnees, le developpeur de 1' application doit identifier avec precision 
les differents traitements possibles accedant simultanement aux donnees. 

Les bases de donnees relationnelles definissent plusieurs niveaux d'isolation. Le 
tableau 12.2 les recapitule, du plus large au plus restrictif. 



Tableau 12.2. Niveaux d'isolation des bases de donnees relationnelles 



Niveau d'isolation 




Description 


TRANSACTION. 


.NONE 




Les transactions ne sont pas supportees. 


TRANSACTION. 


.READ. 


.UNCOMMITTED 


L'application peut rencontrer les trois problemes evoques au tableau 12.1. En cas 
d'absence d'acces concourant aux donnees, ce niveau peut etre utilise afin d'amelio- 
rer les performances. Ce n'est toutefois pas conseille, car la coherence des donnees 
n'est pas completement garantie. 


TRANSACTION. 


.READ. 


.COMMITTED 


Permet de resoudre les lectures non reproductibles, mais l'application peut eventuel- 
lement rencontrer les deux autres problemes. 


TRANSACTION. 


_REPEATABLE_READ 


Permet de resoudre les lectures non reproductibles et les lectures sales. L'application 
peut toutefois rencontrer des lectures fantomes. II s'agit du niveau d'isolation par 
defaut de beaucoup de serveurs de bases de donnees, dont Oracle. 


TRANSACTION. 


.SERIALIZABLE 


Permet de resoudre les trois problemes, mais au prix d'une degradation des perfor- 
mances du fait des verrous poses sur les donnees accedees. 



Pour garantir l'integrite des donnees lors d'une transaction, il est imperatif de positionner 
le niveau d'isolation des donnees de maniere appropriee. II convient pour cela d'evaluer 
avec precision les differents types d'acces aux donnees, notamment les acces concourants 
en modification. 

Plus le niveau d'isolation est restrictif, plus la qualite et la coherence des donnees sont 
garanties. Cependant, comme nous allons le voir par la suite, une gestion de la concou- 
rance est souvent necessaire au niveau applicatif. 



Types de transactions 

II existe deux grands types de transactions, les transactions locales et les transactions 
globales. Leurs principales proprietes sont les suivantes : 

• Transactions locales. Adaptees lorsqu'une seule ressource transactionnelle est 
utilisee. Dans ce cas, le gestionnaire de transactions est la ressource elle-meme. Dans 
l'exemple precedent d' importation, toutes les donnees sont importees dans la meme 
source de stockage des donnees. 

• Transactions globales. Utilisables si une ou plusieurs ressources sont presentes. A 
partir de deux ressources, nous sommes toujours en presence de transactions globales. 
En cas d'utilisation des transactions globales, le gestionnaire de transactions est exter- 
nalise par rapport aux ressources et est capable de dialoguer avec elles grace a des 
interfaces normalisees. Dans notre exemple, les donnees sont importees dans diffe- 
rentes sources de stockage des donnees. 
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Ressource transactionnelle 

On appelle ressource transactionnelle tout module d'acces a un systeme d'information, gerant des tran- 
sactions et offrant une interface de programmation afin de les configurer et de les utiliser. 



L'utilisation d'une seule base de donnees n'implique pas necessairement des transactions 
locales. Par exemple, si l'application utilise en plus JMS comme middleware de messa- 
gerie applicative, les transactions globales sont necessaires afin de realiser des transactions 
utilisant les deux ressources. 

Les transactions globales sont cependant beaucoup plus difficiles a mettre en oeuvre. En 
effet, ce type de transaction necessite la mise en oeuvre d'un gestionnaire de transactions 
externe. Ce dernier est souvent fourni par le serveur d' applications. L' inconvenient de ce 
type de mecanisme vient de la synchronisation des etats transactionnels des ressources et 
de la resolution des incidents. Les systemes peuvent se retrouver dans des etats inco- 
herents, lesquels doivent etre resolus par le biais de choix arbitraires. 

Une autre grande difference entre les transactions locales et globales est que ces dernieres 
se fondent sur l'API uniformisee JTA (Java Transaction API), alors que les transactions 
locales s'appuient directement sur les API des technologies ou frameworks utilises. Nous 
retrouvons cependant toujours des methodes similaires pour demarrer une transaction, 
ainsi qu'une methode pour la valider et une methode pour 1' annul er. 

Cette section ne detaille pas les differentes facons de gerer les transactions locales 
suivant les technologies et frameworks utilises mais se concentre sur la facon de les utili- 
ser avec le framework Spring. Ce dernier masque toute cette complexite et cette diversite 
derriere une API generique. 

Gestion des transactions 

Plusieurs operations peuvent etre realisees afin de manipuler les transactions. II est 
en outre generalement possible de detecter les evenements du cycle de vie d'une 
transaction. 

Demarquer une transaction 

Une transaction est limitee par un debut et une fin. Cette derniere peut survenir aussi bien 
lors d'une validation, en cas de succes, que d'une annulation, en cas d'echec. La demar- 
cation consiste a specifier le commencement et la fin de la transaction. 

Le code suivant montre comment demarquer une transaction avec JDBC : 

Connection connection=null ; 
try { 

//Recuperation de la connexion 
connection=getConnection( ) ; 
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//Demarrage de la transaction 
connecti on . setAutoCommi t( f al se) ; 



//Execution des traitements JDBC de 1 'appl ication 
(...) 



//Validation de la transaction 

connecti on. commitO ; 

connecti on. setAutoCommi t( true) ; 

} catch(SQLException ex) { 
//Gestion des exceptions 

//Annulation de la transaction 
try { 

connecti on. rollbackt ) ; 
connecti on . setAutoCommi t( true ) ; 
} catch(SQLException ex) { } 

} finally { 

//Liberation des ressources JDBC 
try { 

if( connection!=null ) { 
connection. closet); 

} 

} catch(SQLException ex) { } 

} 

En cas de succes d'une transaction, le terme « commit » est communement employe. 
Dans le cas contraire, on parle de « rollback ». Toutes les modifications entre le debut et 
la validation ou annulation de la transaction sont atomiques. 

Suspendre et reprendre une transaction 

Certains frameworks ou technologies permettent de suspendre une transaction dans le but 
de realiser des traitements et de la reprendre une fois ceux-ci termines. L' implementation 
de ces actions se fait de maniere differente suivant le type de transaction choisi. 

Dans le cas des transactions locales, la suspension consiste a ne plus utiliser la connexion 
attachee a la transaction tout en la memorisant, puisqu'elle sera reutilisee quand la tran- 
saction reprendra. Lors de la suspension, une nouvelle connexion est utilisee. Nous 
pouvons en deduire que la suspension est logique et non physique et qu'il incombe au 
framework qui offre cette fonctionnalite de prendre en charge 1' implementation du meca- 
nisme de suspension et de reprise. 

En ce qui concerne les transactions globales, la suspension tout comme la reprise se reali- 
sent directement en utilisant le gestionnaire de transactions et les methodes suspend et 
resume. La premiere renvoie la transaction courante suspendue. Pour la reprendre, la 
methode resume est appelee avec pour parametre cette transaction. L' application doit 
done avoir acces au gestionnaire de transactions globales. 
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Le code suivant evoque la maniere de suspendre et de reprendre une transaction avec 
JTA, 1' API J2EE de gestion des transactions globales : 

// Recuperation du gestionnaire de transactions 
TransactionManager tm=getTransactionManager( ) ; 
// Suspension de la transaction courante 
Transaction transact ion^tm. suspend ( ) ; 
(...) 

// Reprise de cette transaction 
tm. resume (transaction) ; 

Gerer le cycle de vie d'une transaction 

Certains frameworks ou technologies offrent la possibilite de declencher des traitements 
a differents moments du cycle de vie de la transaction. Le terme de synchronisation est 
communement utilise pour designer ce mecanisme. 

Les evenements du cycle de vie pris en compte se produisent essentiellement au moment 
de la validation ou de la finalisation de la transaction. Cela permet de liberer des ressources 
si necessaire. On distingue a cet effet les evenements avant la validation d'une transac- 
tion pour une ressource trans actionnelle (« commit ») et ceux avant ou apres la finalisation 
de la transaction. Des evenements sur la suspension/reprise d'une transaction peuvent 
egalement etre supportes. 

Dans certains cas, comme avec JTA, ce mecanisme est directement integre a l'API de 
gestion des transactions, tandis que des frameworks tels que Spring declenchent les 
evenements au cours du cycle de vie de la transaction. 

Les transactions definissent de maniere classique differents evenements. Ces evene- 
ments, recapitules au tableau 12.3, ne sont toutefois pas tous supportes par toutes les 
technologies ou tous les frameworks. 



Tableau 12.3. Comportements transactionnels 



Evenement 


Description 


Sur la suspension 


Declenche lorsque la transaction est suspendue par I'application. 


Sur la reprise 


Declenche lorsque I'application reprend le deroulement de la transaction. 


Avant la validation 


Declenche avant qu'une ressource transactionnelle soit validee. 


Avant la finalisation 


Declenche avant que la transaction soit validee dans sa globalite. 


Apres la finalisation 


Declenche apres que la transaction a ete validee dans sa globalite. 



Types de comportements transactionnels 

Lorsqu'un composant est rendu transactionnel, il peut etre configure arm de specifier le 
comportement transactionnel de ses methodes. La plupart des frameworks ou technologies 
gerant les transactions definissent des mots-cles pour cela. 
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Le tableau 12.4 recapitule ces mots-cles. II ne s'agit pas a proprement parler d'une speci- 
fication, meme si ces mots-cles sont utilises plus ou moins entierement par des frameworks 
ou technologies tels que Spring ou les EJB. 



Tableau 12.4. Mots-cles de comportements transactionnels 



moi-cie ue comporiemeni 
transactionnel 


Description 


REQUIRED 


La methode doit forcement etre executee dans un contexte transactionnel exis- 
tant. S'il n'existe pas lors de I'appel, il est cree. 


c i innnnTC 

SUPPORTS 


La methode peut etre executee dans un contexte transactionnel s'il existe. Dans 
le cas contraire, la methode est tout de meme executee, mais hors d'un contexte 
transactionnel. 


MANDATORY 


La methode doit forcement etre executee dans un contexte transactionnel. Si tel 
n'est pas le cas, une exception est levee. 


REQUIRED_NEW 


La methode impose la creation d'une nouvelle transaction pour la methode. 


NONSUPPORTED 


La methode ne supporte pas les transactions. Si un contexte transactionnel 
existe lors de son appel, celui-ci est suspendu. 


NEVER 


La methode ne doit pas etre executee dans un contexte transactionnel. Si tel est 
le cas, une exception est levee. 


NESTED 


La methode est executee dans une transaction imbriquee si un contexte transac- 
tionnel existe lors de son appel. 



Ces mots-cles sont utiles lors d'appels entre des methodes de differents composants dans 
un contexte transactionnel, comme des appels entre services metier. 

La figure 12.1 illustre ce qui se passe au niveau des transactions pour ce type d' appel. La 
methode des premier et troisieme composants necessite une transaction (REQUIRED), et 
celle du second aucune (NONSUPPORTED). La transaction initiee par le premier composant 
est done suspendue le temps d'executer la methode du second puis reprend pour executer 
le troisieme. 



Figure 12.1 

Exemple de mecanisme 
transactionnel fonde 
sur les comportements 



Composant 1 

REQUIRED 

Methodel () 



Composant 2 



NOT SUPPORTED 



Methode2() 



Utilisation de la 
transaction courante 



-X- X- 

Suspension de la 
transaction courante 



Composant 3 



REQUIRED 



Methode3() 



Utilisation de la 
transaction courante 
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Le tableau 12.5 recapitule la transaction utilisee par un composant suivant le type de 
comportement transactionnel specifie et la transaction en cours, Tl et T2 designant des 
transactions differentes. 



Tableau 12.5. Types de comportements et transactions 



Type de comportement transactionnel 


Transaction initiale 


Transaction utilisee 


REQUIRED 


Aucune 


T1 




T1 


T1 


SUPPORTS 


Aucune 


Aucune 




T1 


T1 


MANDATORY 


Aucune 


Erreur 




T1 


T1 


REQU I RED_NEW 


Aucune 


T1 




T1 


T2 


NONSUPPORTED 


Aucune 


Aucune 




T1 


Aucune 


NEVER 


Aucune 


Aucune 




T1 


Erreur 


NESTED 


Aucune 


T1 




T1 


T1 (imbriquee) 



Ressources transactionnelles exposees 

Ann de pouvoir utiliser les transactions globales, les fournisseurs de services etendent 
leurs fabriques de connexions afin de les rendre compatibles XA. La specification XA 
(extended Architecture) standardise les interactions entre les gestionnaires de 
ressources et le gestionnaire de transactions afin de mettre en oeuvre des protocoles 
transactionnels. Cela permet de faire participer ces fabriques a une transaction 
globale. 

Le point fondamental pour le composant utilisant la technologie ou le framework est que 
la fabrique exposee est toujours la fabrique simple, et non celle compatible XA. Un 
composant qui utilise les transactions locales ou globales ne voit done pas de difference 
quant aux entites qu'il manipule. Le fournisseur de services ou le serveur d' applications 
a pour sa part la responsabilite de masquer la fabrique XA derriere une fabrique classi- 
que, de fournir une connexion classique et d'ajouter et d'enlever la ressource du contexte 
transactionnel. 

Le passage des transactions locales aux transactions globales n' a done aucun impact sur 
1' utilisation des ressources. La modification est localisee au niveau de la gestion de la 
demarcation. Si celle -ci est declarative, le composant n'est pas impacte par un change - 
ment de type de transaction. Cela favorise fortement la reutilisation des composants dans 
differentes architectures. 
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Concourance d'acces et transactions 

Les applications J2EE utilisant par essence plusieurs fils d' execution pour gerer leurs 
differents traitements, plusieurs acces ou requetes de clients peuvent etre concourants. 

Afin d'eviter les ecrasements de donnees entre utilisateurs, les techniques de verrouillage 
suivantes peuvent etre mises en oeuvre (les techniques decrites ci-apres sont orientees 
base de donnees relationnelle) : 

• Verrouillage pessimiste. Ce mecanisme de verrouillage fort est gere directement par 
le systeme de stockage des donnees. Pendant toute la duree du verrou, aucune autre 
application ou fil d' execution ne peut acceder a la donnee. Pour les bases de donnees 
relationnelles, cela se gere directement au niveau du langage SQL. A l'image d'Hiber- 
nate, plusieurs frameworks facilitent l'utilisation de ce type de verrou. Une requete 
SQL de type select for update est alors utilisee. 

Ce verrouillage particulierement restrictif peut impacter les performances des applica- 
tions. En effet, ces dernieres ne peuvent acceder a l'enregistrement tant que le verrou 
n'est pas leve. Des fils d'execution peuvent done rester en attente et penaliser les 
traitements de 1' application. 

• Verrouillage optimiste. Ce type de verrouillage est plus large et doit etre implemente 
dans 1' application elle-meme. II ne necessite pas de verrou dans le systeme de stockage 
des donnees. Pour les bases de donnees relationnelles, il est generalement implemente 
en ajoutant une colonne aux differentes tables impactees. Cette colonne represente une 
version ou un indicateur de temps indiquant l'etat de l'enregistrement lorsqu'il est lu. 
De ce fait, si cet etat change entre la lecture et la modification, nous nous trouvons dans 
le cas d'un acces concourant. 

L application peut implementer plusieurs strategies pour resoudre ce probleme. 
L'utilisateur peut etre averti, par exemple, une interface conviviale lui offrant la 
possibilite de voir les modifications realisees par un autre utilisateur conjointement 
avec les siennes. II peut des lors effectuer ses mises a jour. L' application peut aussi 
ne pas notifier l'utilisateur et implementer un mecanisme afin de fusionner les differentes 
donnees. 



En resume 

Situees au coeur des applications d'entreprise, les transactions visent a garantir l'inte- 
grite des donnees des systemes d' information. Du fait qu'elles mettent en jeu de 
nombreuses notions qui peuvent etre complexes, il est preferable de les mettre en 
ceuvre en utilisant des technologies ou frameworks encapsulant toute leur complexite 
technique. 

La section suivante detaille la facon de les mettre en oeuvre, ainsi que les pieges a eviter 
et la solution fournie par le framework Spring. 
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Mise en oeuvre des transactions 

Depuis le debut de ce chapitre, nous avons rappele les differentes proprietes des transac- 
tions. Nous abordons a present leur mise en oeuvre optimale et de la facon la plus trans- 
parente possible pour les composants des applications Java/J2EE. L'objectif vise n'est 
pas d'incorporer les mecanismes transactionnels dans le code des composants applicatifs 
mais de le specifier au moment de leur assemblage. 

Integrer les notions transactionnelles dans l'architecture d'une application n'est pas chose 
aisee, tant les concepts en jeu sont nombreux. Les principaux defis sont de conserver la 
modularite des composants, l'isolation des couches et la separation des codes technique et 
metier. 

Ann de concilier les bonnes pratiques abordees au cours des chapitres precedents et la 
gestion transactionnelle, la demarcation doit etre correctement appliquee et le comporte- 
ment transactionnel des composants judicieusement utilise. Pour cela, l'utilisation de 
frameworks ou de technologies appropries est indispensable. 



Gestion de la demarcation 

La demarcation transactionnelle doit etre realisee au niveau des services metier. Ces 
derniers peuvent s'appuyer sur plusieurs composants d'acces aux donnees. Plusieurs 
appels a des methodes de ces composants sous-jacents peuvent done etre realises dans 
une meme transaction. 

Le support des transactions doit de plus etre suffisamment flexible pour permettre de gerer les 
appels entre services. La definition de types de comportement transactionnel rend ce support 
flexible et declaratif. Spring implemente ces strategies dans sa gestion des transactions. 

La figure 12.2 illustre les couches applicatives impactees par la gestion des transactions, 
qui est une problematique transversale. 



Couche 
presentation 



Couche 
application 



Couche 
services metier 



Couche 
acces aux 
donnees 



Couche 
persistance 



Portee du contexte transactionnel 
et composants transactionnels 



Demarcation 
transactionnelle 



Figure 12.2 

Impact de la gestion transactionnelle sur les couches applicatives 
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Dans notre etude de cas, 1' application des comportements transactionnels est mise en 
oeuvre sur les composants du package tudu. service. impl. 



Mauvaises pratiques et anti-patterns 

La structuration des preoccupations en couches constitue une bonne pratique elemen- 
taire, chaque couche ne devant avoir connaissance que de la couche immediatement infe- 
rieure. 

Les composants services metier ne doivent s'appuyer que sur les composants d'acces aux 
donnees et ne peuvent en aucun cas avoir connaissance des API utilisees par ces compo- 
sants pour acceder aux donnees. Cependant, la tentation est grande d'utiliser les API de 
persistance pour demarquer les transactions au niveau de la couche metier et de passer 
ensuite ces instances aux couches inferieures. Par exemple, l'utilisation d'une connexion 
JDBC ou d'une session d'un ORM dans la couche service metier est un anti -pattern. 

Le code suivant est un bon exemple de mise en oeuvre de cet anti-pattern. II montre un 
composant de la couche service metier qui s'appuie sur une connexion JDBC afin de 
debuter et valider ou d' annuler une transaction locale. Cette connexion est ensuite passee 
au composant d'acces aux donnees utilise afin d'inclure les traitements du composant 
dans la transaction. 

Nous considerons dans ce code que l'instance myDao du composant d'acces aux donnees a 
ete correctement recuperee precedemment : 

Connection connect!' on=nul 1 ; 
try { 

//Recuperation de la connexion 
connection=getConnection( ) ; 

//Demarrage de la transaction 
beginTransaction(connection) ; 

//Execution des traitements du DAO utilise 
my Dao.update( connection, my Entity) ; 

//Validation de la transaction 
commi tTransacti on (connection) ; 
} catch(SQLException ex) { 
//Gestion des exceptions 

//Annulation de la transaction 
rol 1 backTransacti on ( connect i on) ; 
} finally { 

//Liberation des ressources JDBC 
closeConnection(connection) ; 

} 
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II existe un couplage fort entre les technologies utilisees par les composants de la couche 
d'acces aux donnees et les services metier, ces derniers utilisant ces technologies explici- 
tement. Cette pratique nuit grandement a la flexibilite, a la modularite, a l'evolutivite et a 
la separation des preoccupations. 

Une bonne pratique consiste a masquer l'utilisation de ces API derriere une API generi- 
que de gestion transactionnelle. Cette API doit etre programmed a l'aide d'interfaces afin 
de cacher 1' implementation de ce gestionnaire. Ce dernier peut eventuellement s'appuyer 
sur un contexte transactionnel pour le fil d' execution et etre stocke dans une instance de 
type ThreadLocal . Cette classe de base de Java permet de garder une instance pouvant 
rester accessible pour tout un fil d' execution. 

La section suivante detaille comment Spring permet de gerer facilement et de facon 
modulaire les transactions dans les applications Java-J2EE a l'aide de bonnes pratiques 
de conception et de fonctionnalites permettant de specifier des comportements transac- 
tionnels de maniere declarative. 

L'approche de Spring 

L'une des fonctionnalites les plus attractives de Spring est indiscutablement celle qui 
concerne la gestion des transactions, car elle offre une souplesse et une facilite d' utilisation 
sans egales dans le monde Java/J2EE. 

La strategie de Spring est en outre entierement configurable et modulaire. Nous verrons 
qu'il existe deux approches pour gerer la demarcation, s'appuyant toutes deux sur une 
API de demarcation generique, et plusieurs implementations de la strategie transaction- 
nelle en fonction des ressources utilisees. Spring permet ainsi de s'adapter aux besoins de 
l'application et de maitriser le degre d'intrusivite ainsi que les performances de la gestion 
des transactions en utilisant le type de transaction approprie. 

Spring permet en outre de definir des comportements transactionnels sur les composants 
par declaration. 

Une API generique de demarcation 

Les concepteurs de Spring ont identifie le besoin d'une API generique afin de gerer la 
demarcation transactionnelle et de specifier le comportement transactionnel d'un 
compos ant. 

Cette API comporte deux grandes parties, la partie cliente et la partie fournisseur de 
services. 

Partie cliente 

La partie cliente permet de demarquer explicitement la transaction, soit directement avec 
les API transactionnelles de Spring, soit indirectement avec un template transactionnel 
ou un intercepteur. 
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Toutes les classes et interfaces decrites dans cette section sont localisees dans le package 
org. springframework. transaction du framework. 

Le premier element du support transactionnel est l'interface PI atformTransactionManager, 
qui permet de demarquer une transaction, et ce, quelles que soient les ressources et stra- 
tegies transactionnelles utilisees. Cette interface fournit des methodes de validation et 
d'annulation pour la transaction courante : 

public interface PlatformTransactionManager { 
TransactionStatus getTransaction( 

Transacti onDef i ni ti on def i ni ti on ) 

throws TransactionException; 
void commit(TransactionStatus status) 

throws TransactionException; 
void rollbacktTransactionStatus status) 

throws TransactionException; 

} 

Pour commencer une transaction, les proprietes et comportements transactionnels 
suivants doivent etre specifies : 

• isolation transactionnelle ; 

• type de comportement transactionnel ; 

• temps d' expiration des transactions ; 

• statut lecture seule. 

Ces proprietes sont contenues dans l'interface TransactionDefinition suivante : 

public interface TransactionDefinition { 

int PROPAGATION_REQUI RED = 0; 

int PR0PAGATI0N_SUPP0RTS = 1; 

int P R0 PAGAT 1 0N_MAN DATO RY = 2; 

int PROPAGATION_REQUIRES_NEW = 3; 

int PR0PAGATION_NOT_SUPPORTED = 4; 

int P R0 P AG AT 1 0 N_N EVER = 5; 

int PR0PAGATI0N_NESTED = 6; 



int I SO LAT I0N_DEFAL)LT = -1; 

int IS0LATI0N_READ_UNC0MMITTED = 

Connection .TRANSACT 1 0N_READ_UNCOMMITTED; 
int IS0LATI0N_READ_C0MMITTED = 

Connection .TRANSACTI 0N_READ_C0MMITTED; 
int ISOLATION_REPEATABLE_READ = 

Connection . TRANSACTI ON_REPEATABLE_READ ; 
int IS0LATI0N_SERIALIZABLE = 

Connection .TRANSACT I ON_SERIALIZABLE; 
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int getPropagationBehavior( ) ; 
int getlsol ationLevel ( ) ; 
int getTimeoutt ) ; 
boolean isReadOnly( ) ; 
String getNamet ) ; 

} 

Spring supporte tous les types de comportements transactionnels decrits precedemment. 
Les mots-cles correspondants different toutefois legerement des mots-cles generaux, 
comme le montre le tableau 12.6. 



Tableau 12.6 Comportements transactionnels de Spring 



Comportement transactionnel general 


Mot-cle Spring 


REQUIRED 


PROPAGATION_REQUI RED 


SUPPORTS 


PROPAGATION_SUPPORTS 


MANDATORY 


PROPAGATION_MANDATORY 


REQUIRED_NEW 


PROPAGATION_REQUIRED_NEW 


NONSUPPORTED 


PR0PAGATI0N_N0T_SUPP0RTED 


NEVER 


PROPAGATION_NEVER 


NESTED 


PROPAGATION_NESTED 



Une fois la transaction demarree, Spring impose de conserver une instance de son statut, 
materialisee par 1' interface Transact!' onStatus suivante : 

public interface TransactionStatus { 
boolean isNewTransaction( ) ; 
void setRol 1 backOnly( ) ; 
boolean isRollbackOnlyt ) ; 

} 

En plus des methodes de visualisation de proprietes de la transaction courante (methode 
isNewTransaction et i sRol 1 backOnly), cette interface definit une methode setRol 1 backOnly, 
qui permet de specifier que la transaction doit etre annulee quels que soient les traite- 
ments ulterieurs. Ce mecanisme est semblable a celui des EJB, si ce n'est que, dans le cas 
de Spring, il est uniformise pour tous les types de transactions, locales comme globales, 
ou de ressources pour ce qui concerne les seules transactions locales. 

Lors de l'utilisation directe de l'API cliente de Spring, la gestion des exceptions et du 
comportement transactionnel est de la responsabilite de 1' application, alors que, en cas 
d' utilisation du template transactionnel, la levee d'une exception implique forcement, 
par defaut, une annulation de la transaction. 

Nous verrons en detail l'utilisation de cette API a la section decrivant la fagon de demarquer 
les transactions. 



Partie fournisseur de services 



La partie fournisseur de services de l'API generique est constitute par les implementa- 
tions de l'interface PlatformTransactionManager. Spring les designe sous la denomination 
de gestionnaire de transactions et fournit une multitude d' integrations avec differentes 
technologies et frameworks d'acces aux donnees, qui se fondent sur les ressources de 
la technologie ou du framework. 

Les tableaux 12.7 a 12.10 recapitulent ces differentes implementations technologie par tech- 
nologie. Ces implementations sont localisees dans les packages correspondant aux techno- 
logies ou frameworks utilises. 

Tableau 12.7. Implementation fondee sur JDBC 



Technologie 


Gestionnaire de transactions 


Ressource utilisee 




JDBC 


DataSourceTransacti onManager 


DataSource 




Tableau 12.8. Implementations fondees sur des frameworks ORM 


Framework 


Gestionnaire de transactions 


Ressource utilisee 




Hibernate 2.1 


Hi bernateTransacti onManager 


SessionFactory 




Hibernate 3 


Hi be rnateTrans act i onManager 


SessionFactory 




iBATIS 


DataSourceTransacti onManager 


DataSource 




JDO 


JdoTr a ns a cti onManager 


Persi s ten ceManager Factory 




OJB 


Persi s ten ceBrokerTrans act i on- 
Manager 


DataSource 




TopLink 


Top Li nkTr ansa cti onManager 


SessionFactory (dans le cas de TopLink, oette classe est 
specifique de Spring et non de I'outil), DataSource. 


Tableau 12.9. Implementations fondees sur des middlewares 


Middleware 


Gestionnaire de transactions 


Ressource utilisee 




JMS 1.02 


JmsTr ansa cti onManager 102 


ConnectionFactory (dans le cas de JMS 1.02, il est 
necessaire de specifier le type de ressource, Queue ou 
Topic, avec la propriete pubSubDomain). 


JMS1.1 


JmsTr ansa cti onManager 


ConnectionFactory 




JCA 


Cci LocalTransactionManager 


ConnectionFactory 




Tableau 12.10. Implementation fondee sur les transactions XA 


Technologie 


Gestionnaire de transactions 


Ressource utilisee 





XA JtaTransactionManager UserTransaction, TransactionManager 
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Injection du gestionnaire de transactions 

Pour utiliser la gestion des transactions de Spring, le choix du gestionnaire de transac- 
tions est primordial. En fonction du type de demarcation utilise, ce gestionnaire n'est pas 
injecte sur les memes entites. 

Dans le cas de la demarcation par programmation, le composant service utilise ce 
gestionnaire directement ou via le template transactionnel. Le gestionnaire de transac- 
tions doit done etre injecte sur le composant. Cette injection est configured dans le fichier 
de configuration applicationContext.xml localise dans le repertoire WEB-INF : 

<bean id="transactionManager" 
cl ass="org.springf ramework.orm. 

hibernate. Hi bernateTransactionManager"> 
<property name=" ses si on Factory "> 
<ref bean="sessionFactory"/> 
</property> 
</bean> 

<bean id="todosManager" cl ass="tudu.servi ce. impl .TodosManagerlmpl "> 
(...) 

<property name="transactionManager"> 
<ref bean="transactionManager"/> 
</property> 
</bean> 

Dans le cas de la demarcation declarative, cette responsabilite incombe desormais a l'inter- 
cepteur transactionnel de Spring. Le gestionnaire doit done etre injecte sur l'intercepteur : 

<bean id="transactionManager" 
cl ass="org.springf ramework.orm. 

hibernate. Hi berna teTrans act ionManager"> 
<property name=" ses si on Factory "> 
<ref bean="sessionFactory"/> 
</property> 
</bean> 

<bean id="todoListsManager" 

class="org.springframework. transaction 

. interceptor .Trans act ion Proxy Factory Bean" > 
<property name="transactionManager"> 
<ref bean="transactionManager"/> 
</property> 
(...) 
</bean> 

L'etude de cas Tudu Lists utilise cette approche afin de specifier les comportements tran- 
sactionnels sur les composants. L' injection du gestionnaire de transactions se fait done de 
cette maniere. Cette configuration est realisee dans le fichier applicationContext.xml, 
localise dans le repertoire /WEB-INF. 
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Gestion de la demarcation 

Maintenant que nous avons decrit les principes de la gestion des transactions avec 
Spring, nous pouvons detailler les differentes approches de gestion de la demarcation, 
par programmation et par declaration. 

Gestion de la demarcation par programmation 

Spring offre deux facons de realiser cette demarcation. La premiere utilise directement 
les API generiques de Spring, dont l'interface principale est PI atformTransactionManager. 
La gestion des exceptions est a la charge du developpeur. La seconde utilise la classe 
TransactionTemplate, le template de Spring dedie a la gestion des transactions fournissant 
une methode de rappel a implementer avec les traitements de la transaction. Dans ce cas, 
le developpeur n'a qu'a se concentrer sur les traitements specifiques de l'application. 

La definition des proprietes transactionnelles est effectuee grace aux implementations 
de l'interface TransactionDefinition. La plus communement utilisee est la classe 
DefaultTransactionDefinition, mais il en existe d'autres, comme la classe RuleBased- 
TransactionAttribute. Ces differentes implementations se trouvent toutes dans le package 
org.springf ramework. trans act ion. support. 

Cette interface permet de specifier differentes constantes concernant la propagation tran- 
sactionnelle et les niveaux d' isolation. Elle offre egalement des accesseurs sur le niveau 
d'isolation, le nom de la transaction, le type de propagation, le delai d'expiration, l'attri- 
but lecture seule, etc. Cette interface a deja ete abordee a la section « Partie cliente » de 
ce chapitre. 

La definition des comportements face aux differentes exceptions ne peut etre configuree 
avec cette approche. La responsabilite en incombe a l'application, qui utilise directement 
les API transactionnelles de Spring. Nous verrons avec 1' approche declarative que Spring 
offre la possibility de configurer ce comportement et de rendre ainsi la demarcation des 
transactions particulierement flexible. 

Le code suivant illustre 1' utilisation des API generiques de Spring afin de realiser une 
demarcation transactionnelle. Dans cet exemple, le gestionnaire de transactions (instance 
transactionManager) de Spring est injecte a l'aide des fonctionnalites dediees de Spring et 
est done disponible pour un composant de la couche service metier tel que l'implementa- 
tion TodosManagerlmpl (package tudu. service. impl) de l'etude de cas. Ce composant 
contient desormais le code suivant : 

1 DefaultTransactionDefinition def= 

2 new DefaultTransactionDefinitionO; 

3 def .setPropagationBehavior( 

4 TransactionDefinition. PROPAGATION_REQUI RED) ; 
5 

6 TransactionStatus status=transactionManager.getTransaction(def ) ; 
7 
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8 try { 

9 // Differents traitements metier de 1' application ou 

10 // utilisation de composants d'acces aux donnees 

11 } catch (BusinessException ex) { 

12 transact!' onManager. rollbackt status) ; 

13 throw ex; 

14 } 

15 transactionManager.cominit(status) ; 

Les lignes 1 a 4 permettent de specifier les proprietes et le comportement transactionnels 
des traitements. La ligne 6 marque le debut de la transaction en s'appuyant sur le gestion- 
naire de transactions injecte avec Spring. La fin de la transaction peut etre realisee de 
deux manieres, toujours en s'appuyant sur le gestionnaire. 

Si tout se passe bien, la transaction est validee a la ligne 15 ; si une exception se produit, 
la transaction est annulee a la ligne 12. 

Tous les traitements du bloc try/catch fondes sur la meme technologie que le gestion- 
naire sont automatiquement inclus dans la transaction. Si l'approche d'enregistrement 
automatique dans le contexte transactionnel n'est pas utilisee, les composants d'acces 
aux donnees doivent necessairement utiliser les methodes utilitaires de Spring pour recuperer 
et relacher les connexions ou sessions. 

Le code suivant illustre 1' utilisation du template transactionnel de Spring pour realiser 
une demarcation transactionnelle dans un composant de la couche service metier tel que 
1' implementation TodosManagerlmpl (package tudu. service. impl) de l'etude de cas. Dans 
cet exemple, le gestionnaire de transactions (instance transacti onManager) de Spring est 
egalement injecte a l'aide de l'injection de dependance : 

1 TransactionTempl ate tempi ate=new TransactionTemplateO; 

2 tempi ate. setTransacti onManager (transacti onManager) ; 
3 

4 Object result=template.execute(new TransactionCallbackO { 

5 public Object doInTransactiondransactionStatus status) { 

6 // Differents traitements metier de 1 'appl ication ou 

7 // utilisation de composants d'acces aux donnees 

8 return (...); 

9 } 
10 }); 

L'appel au template se fait a la ligne 4, lors de l'invocation de la methode execute. Cette 
derniere attend comme parametre une implementation de l'interface Transacti onCal 1 back, 
specifiant les traitements a realiser dans la transaction. En effet, la methode execute 
demarre tout d'abord une transaction en se fondant sur le gestionnaire specifie puis 
appelle la methode de rappel doInTransaction et valide ou annule la transaction suivant le 
resultat des traitements (exceptions non verifiees levees). 
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Gestion de la demarcation par declaration 

La demarcation par declaration est a utiliser en priorite, car elle n'est pas intrusive pour 
le composant service metier. Le code technique des transactions est en effet externalise 
par rapport au code metier du composant. De plus, le comportement transactionnel peut 
etre specine a l'assemblage des composants. 

Cette demarcation consiste d'abord a injecter dans l'intercepteur de gestion des transac- 
tions les proprietes de la transaction sous forme de chaines de caracteres dont les diffe- 
rents elements sont separes par des virgules. Spring implemente sur ces elements un 
mecanisme permettant de reconnaitre le type de la propriete : 

• Si l'element commence par PROPAGATION^ il designe un type de comportement transac- 
tionnel. 

• Si l'element commence par ISOLATION., il designe le niveau d'isolation. 

• Si l'element commence par timeout_, il specifie le delai d'attente de la transaction. 

• Si l'element correspond a readOnl y, la transaction est en lecture seule. 

• Si l'element commence par le caractere +, la levee de 1' exception dont le nom suit ce 
caractere provoque une validation de la transaction. 

• Si l'element commence par le caractere -, la levee de 1' exception dont le nom suit ce 
caractere provoque une annulation de la transaction. 

Les chaines de description des proprietes transactionnelles sont de la forme : 

PROPAGATION_REQUIRED, -MyCheckedException 
PROPAGATION_REQUIRED, ISOLATION_REPEATABLE_READ 
PROPAGATION_REQUI RED, readonly 

Voyons maintenant comment associer ces proprietes aux intercepteurs transactionnels de 
Spring. 

Spring permet d'injecter ces proprietes transactionnelles grace a deux types de proprietes : 

• propriete de type Properties ; 

• propriete de type Transact! onAttributeSource. 

Dans le premier cas, l'attribut se nomme transactionAttributes pour la classe Transac- 
tionProxyFactoryBean ou l'intercepteur Transactionlnterceptor. Son utilisation se realise 
par le biais du support du type Properties par le framework : 

<bean id="todol_istsManager" 

cl ass= "org. springf ramework. transact ion 

. interceptor .Trans action Proxy Factory Bean" > 

(...) 

<property name="transactionAttributes"> 
<props> 
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<prop key="insert*">PROPAGATION_REQUIRED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 

La cle des differentes proprietes constitue une expression reguliere permettant de deter- 
miner la ou les methodes concernees. Dans l'exemple ci-dessus, la classe Transaction- 
Interceptor peut etre utilisee en lieu et place de la classe TransactionProxyFactoryBean. 

Dans le second cas, l'attribut se nomme transactionAttributeSource pour la classe Tran- 
sactionProxyFactoryBean ou l'intercepteur Transactionlnterceptor. Comme Spring fournit 
le gestionnaire de proprietes (PropertyEditor) dedie, TransactionAttributeEditor, les attri- 
buts trans actionnels peuvent etre configures sous forme de chaines de caracteres ou 
d'instances de la classe TransactionAttributeSource. 

L'exemple suivant montre comment specifier cette propriete en tant que chaine de carac- 
teres : 

<bean id="myTransact ion Interceptor" class="org.springf ramework. 

transaction .interceptor. Transact ion Interceptor "> 

(...) 

<property name="transactionAttributeSource"> 
<val ue> 

MaClasse.maMethode*=PROPAGATION_REQUIRED 
MonAutreCl asse.monAutreMethode=PROPAGATION_MANDATORY 
</val ue> 
</property> 

</bean> 

Dans cet exemple, la classe TransactionProxyFactoryBean peut etre utilisee a la place de la 
classe Transactionlnterceptor. 

Pour configurer une instance de TransactionAttributeSource, une de ses nombreuses 
implementations peut etre utilisee : 

• AttributesTransactionAttributeSource. S'appuie sur des annotations common attributes 
dans le ou les composants impactes. 

• MatchAlwaysTransactionAttributeSource. S'applique a toutes les methodes du ou des 
composants impactes. 

• MethodMapTransactionAttributeSource. Utilise une table de hachage pour definir les 
attributs pour les methodes. 

• NameMatchTransactionAttributeSource. S'appuie sur les noms de methodes pour deter- 
miner les attributs transactionnels correspondants. Lapproche fondee sur la classe 
Properties utilise implicitement cette classe. 

• AnnotationTransactionAttributeSource. S'appuie sur les annotations Java 5 placees 
dans les composants impactes. 



Gestion des donnees 

Partie III 



L'exemple suivant montre comment configurer les attributs transactionnels en se fondant 
explicitement sur une implementation de Transacti onAttri buteSource : 

<!-- Proprietes de la transaction --> 

<bean id="matchAl lWithPropReq" class="org.springframework. 
transacti on . i nterceptor .MatchAl waysTransacti onAttri buteSource"> 
<property name="transacti onAttri bute"> 
<val ue>PROPAGATION_REQUIRED</val ue> 
</property> 
</bean> 

<!-- Configuration de 1 'intercepteur transactionnel --> 
<bean id="matchAllTxInterceptor" class="org.springframework. 

trans action. interceptor. Transact ion I nterceptor "> 

(...) 

<property name="transacti onAttri buteSource"> 

<ref bean="matchAl lWithPropReq"/> 
</property> 

</bean> 

Nous allons voir comment utiliser les intercepteurs transactionnels de Spring, le 
framework offrant un certain nombre de fonctionnalites pour masquer la complexite de la 
POA dans le cadre des transactions. Comme le support des transactions par declaration 
s'appuie sur le framework POA de Spring, 1' application du comportement transactionnel 
sur des composants peut etre realisee composant par composant ou sur un ensemble de 
composants. 

Utilisation de TransactionProxyFactoryBean 

Dans ce cas, un proxy est defini devant le composant service metier implique. Ce proxy 
masque 1' intercepteur transactionnel et simplifie done 1' utilisation de la POA pour les 
transactions. 

Pour configurer ce mecanisme, il faut d'abord renommer 1'identinant du Bean 
service metier dans Spring. Une methode classique consiste a le suffixer avec Target. 
L'identifiant originel du Bean est alors donne au proxy lui-meme. Le proxy doit 
evidemment etre relie au Bean cible par la propriete target. II ne faut pas non plus 
oublier de specifier le gestionnaire de transactions utilise a l'aide de la propriete 
transacti onManager. 

L' application utilise desormais de maniere transparente le proxy, lequel se fonde sur le 
Bean cible. Les composants qui utilisent ce dernier n'ont pas connaissance de ce changement 
de configuration. 

Le code suivant illustre la mise en ceuvre de cette approche dans l'etude de cas. II est 
extrait du fichier de configuration XML applicationContext.xml situe dans le repertoire 
WEB-INF : 

<bean id="todoListsManagerTarget" 

cl ass="tudu. service. impl .TodoLi stsManagerlmpl "> 
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<property name="todoLi stDA0"> 
<ref bean="todoListDAO"/> 
</property> 

<property name="todoDAO"> 
<ref bean="todoDAO"/> 

<property name="userManager"> 
<ref bean="userManager"/> 

</property> 
</bean> 



<bean id="todoListsManager" 

cl ass= " org. springf ramework. transaction 

. interceptor .Trans act ion Proxy Factory Bean" > 
<property name="transactionManager"> 
<ref bean="transactionManager"/> 
</property> 

<property name="target"> 

<ref bean="todoListsManagerTarget"/> 
</property> 

<property name="transactionAttributes"> 
<props> 

<prop key=" create*" >PROPAGATION_REQU I RED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="delete*">PROPAGATION_REQUIRED</prop> 
<prop key="add*">PROPAGATION_REQUIRED</prop> 
<prop key="restore*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 

Utilisation de Transactionlnterceptor 

Dans ce second cas, le framework POA de Spring est utilise explicitement. Cette mise en 
oeuvre est plus complexe, car elle necessite une connaissance des notions de la POA 
(point de jonction, coupe, code advice et intercepteur) et l'utilisation de l'intercepteur 
transactionnel de Spring materialise par la classe Transactionlnterceptor. Elle utilise la 
fonctionnalite Auto Proxy Creator de Spring pour une liste de Beans specifiee ou la classe 
ProxyFactoryBean pour un Bean particulier. 

Pour information, la classe TransactionProxyFactoryBean precedente s'appuie elle aussi 
sur cet intercepteur mais le masque, facilitant d'autant son utilisation. 

Commencons par detailler l'utilisation du mecanisme Auto Proxy Creator. Une de ses 
implementations est la classe BeanNameAutoProxyCreator, qui utilise le nom des Beans pour 
le tissage. Comme ce dernier est automatique, la modification du nom des Beans service 
metier n'est plus necessaire. 
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Le code suivant illustre la facon de mettre en oeuvre une configuration equivalente a la 
precedente, mais avec le mecanisme Auto Proxy Creator. Cette configuration est a placer 
dans le meme fichier que precedemment : 

<!-- Configuration de l'intercepteur transactionnel --> 
<bean id="transactionInterceptor" class="org.springframework. 

transact ion. interceptor. Transact ion I nterceptor"> 
<property name= "trans act ionManager"> 
<ref bean="transactionManager"/> 
</property> 

<property name=" transact ion Attributes'^ 
<props> 

<prop key=" create*" >PROPAGATION_REQU I RED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="del ete*">PROPAGATION_REQUIRED</prop> 
<prop key="add*">PROPAGATION_REQUIRED</prop> 
<prop key="restore*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 

<!-- Tissage de l'intercepteur --> 

<bean id="autoProxyCreator" class="org.springframework.aop. 

framework. autoproxy.BeanNameAutoProxyCreator"> 
<property name="interceptorNames"> 

<1 istXidref local="transactionInterceptor"/X/l ist> 
</property> 

<property name="beanNames"> 

<1 istXidref local ="todoListsManager"/X/l ist> 
</property> 
</bean> 

Comme explique precedemment, des implementations de l'interface TransactionAttribute- 
Source peuvent etre utilisees explicitement par le biais de la propriete transact! on- 
AttributeSource. 

Utilisation des espaces de nommage 

Comme nous l'avons vu precedemment, la version 2.0 du framework Spring introduit le 
support des espaces de nommage dans les fichiers de configuration des contextes. 

Des espaces de nommage specifiques ont ete ajoutes arm d'adresser les problematiques rela- 
tives a la POA, ainsi qu'a la gestion des transactions et de simplifier leur configuration. 

L'exemple suivant illustre l'adaptation de la configuration des transactions de la section 
precedente avec le support des espaces de nommage : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns="http: //www. spri ngframework.org/schema/beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xmlns:aop="http: //www. spri ngframework.org/schema/aop" 
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xml ns : tx="http : //www. spri ngframework.org/schema/tx" 

xsi : schema Location= 

"http://www.springframework.org/schema/beans 
http : //www. spri ngf ramework.org/schema/beans/spring-beans .xsd 
http://www.springframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop.xsd 
http://www.springframework.org/schema/tx 
http://www.springframework.org/schema/transaction/spring-tx.xsd"> 

(...) 

<aop:config> 
<aop:advisor 

pointcut="execution(* *. .TodoListsManagerlmpl .*(..))" 
advice- ref="txAdvice"/> 
</aop:config> 

<tx:advice id="txAdvice"> 
<tx:attributes> 

<tx:method name="create*"/> 

<tx:method name="update*"/> 

<tx:method name="delete*"/> 

<tx:method name="add*"/> 

<tx:method name="restore*"/> 

<tx:method name="*" read-only="true"/> 
</tx:attributes> 
</tx:advice> 

(...) 

</beans> 

La configuration se realise en deux etapes. La premiere consiste a configurer le tissage de 
l'aspect transactionnel avec la balise conf ig pour l'espace de nommage aop. La seconde met 
en oeuvre la configuration transactionnelle par le biais du code advice materialise par la 
balise advice pour l'espace de nommage tx. Ann d'alleger la configuration, cette balise 
utilise des valeurs par defaut pour les proprietes vues precedemment. 

Nous detaillons dans la suite de ce chapitre une implementation permettant de specifier 
des comportements transactionnels avec des annotations Java 5. Pour plus de details sur 
les autres implementations, se reporter aux javadocs du framework Spring. 

Synchronisation des transactions 

Comme pour les EJB, Spring offre la possibilite a une classe d'etre notifiee a certains 
moments du cycle de vie de la transaction courante. II suffit d'utiliser l'interface 
TransactionSynchronization pour specifier 1' implementation de la synchronisation et 
la classe TransactionSynchronizationManager pour l'enregistrer dans la transaction 
courante. 
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Le code suivant en donne un exemple d'utilisation : 

Transact ionSynchronizationManager. registerSynchronization( 
new TransactionSynchronization( ) { 
public void suspendO { } 
public void resumeO { } 
public void beforeCommit(boolean readonly) { 
System. out. printlnC'before commit") ; 

} 

public void beforeCompletion( ) { } 
public void afterCompleti on (final int status) { 
System. out. print! n( "after completion") ; 

} 

}); 



Gestion des exceptions 

Spring offre un mecanisme interessant pour specifier la maniere de terminer une transac- 
tion lorsqu'une exception est levee. Le framework propose un comportement par defaut 
similaire a celui des EJB (validation pour les exceptions verifiees et annulation pour 
les exceptions non verifiees) mais peut aussi etre completement parametre en utilisant les 
attributs de la transaction. Ce mecanisme ne peut etre mis en ceuvre qu'avec l'approche 
de gestion des transactions par declaration. 

Si, par exemple, la levee d'une exception verifiee doit entrainer une annulation de la tran- 
saction, il suffit d'utiliser la configuration suivante : 

(...) 

<property name="transactionAttributes"> 
<props> 
<prop key="create*"> 

PROPAGATION_REQUIRED,-CheckedException 
</prop> 

<prop key="update*">PROPAGATION_REQUIRED</prop> 

<prop key="del ete*">PROPAGATION_REQUIRED</prop> 

<prop key="add*">PROPAGATION_REQUIRED</prop> 

<prop key="restore*">PROPAGATION_REQUIRED</prop> 

<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
(...) 

Le signe - permet de definir une annulation lors de la levee de l'exception correspondante, 
et le signe + une validation. 

Fonctionnalites avancees 

Spring fournit quelques fonctionnalites interessantes facilitant et allegeant la mise en ceuvre 
des transactions dans une application Java/J2EE, comme l'utilisation transparente du 
contexte transactionnel, l'heritage des configurations transactionnelles ou les annotations. 
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Utilisation transparente du contexte transactionnel 

Spring est devenu maitre dans l'art d'integrer des frameworks tiers dans une application de la 
maniere la plus optimale et modulaire possible. II fournit egalement un mecanisme interes- 
sant afin d'ajouter un composant dans un contexte transactionnel gere par Spring de maniere 
transparente, le composant n'ayant pas forcement besoin d' avoir ete developpe avec Spring. 

Spring fournit ces types de proxy sur les ressources transactionnelles pour differentes 
technologies. Ces proxy ont par convention un nom commencant par Transact! onAwa re. 
lis integrant automatiquement les connexions ou sessions dans le contexte transactionnel 
de Spring, si bien que les composants peuvent ne plus utiliser les classes utilitaires de 
Spring pour recuperer et relacher ces ressources. 

Le code suivant montre comment configurer ce mecanisme avec JDBC (cette mise en 
oeuvre ne depend pas de 1' implementation de l'interface DataSource choisie) : 

<bean id="dataSourceTarget" class="org. spring-framework. jdbc. 

da tasource.Dri verManager DataSource "> 
<property name="dri verCl ass Name "> 

<val ue>org. hsql db. jdbcDri ver</val ue> 
</property> 
<property name="url"> 

<value>jdbc: hsql db: hsql : //local host :9001</value> 
</property> 

<property name="username"Xval ue>sa</val ue></property> 
<property name=" pas sword "Xval ue/X/property> 
</bean> 

<bean id="dataSource" class="org.springframework.jdbc. 

datasource.TransactionAwareDataSourceProxy"> 
<property name="dataSource"> 

<ref local ="dataSourceTarget"/> 
</property> 
</bean> 

Heritage des configurations transactionnelles 

Dans une entree de son blog (http://blog.exis.com/colin/), Colin Sampaleanu, un des principaux 
developpeurs de Spring, decrit une facon interessante de configurer les transactions dans 
Spring. 

II montre comment utiliser l'heritage dans la configuration des Beans afin d'alleger la 
configuration transactionnelle. II distingue une configuration transactionnelle globale et 
une configuration au cas par cas, heritant de la precedente. Le fichier XML de confi- 
guration de Spring est beaucoup plus concis dans le cas ou beaucoup de composants 
transactionnels sont configures : 

<!-- Proxy transactionnel generique --> 
<bean id="transactionProxy" abstract="true" 
cl ass="org.springf ramework.tr ansact ion 

. interceptor .Transact ion Proxy Factory Bean" > 
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<property name= "trans act ionManager"> 
<ref bean="transactionManager"/> 
</property> 

<property name=" trans act ion Attributes'^ 
<props> 

<prop key="insert*">PROPAGATION_REQUIRED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 



<!-- Bean transactionnel cible --> 
<bean id="todol_istsManagerTarget" 

cl ass="tudu. service, impl .TodoLi stsManagerlmpl "> 
<property name="todol_i stDA0"> 
<ref bean="todoListDAO"/> 
</property> 

<property name="todoDAO"> 

<ref bean="todoDAO"/> 
<property name="userManager"> 

<ref bean="userManager"/> 
</property> 
</bean> 



<!-- proxy transactionnel sur la cible --> 

<bean id="todol_istsManager" parent="transactionProxy"> 

<property name="target"> 

<ref bean="todoLi stsManagerTarget"/> 

</property> 
</bean> 

Cette approche est a utiliser essentiellement avec l'approche fondee sur la classe Transac- 
tionProxyFactoryBean et n'offre que peu d'interet avec le mecanisme Auto Proxy Creator. 

Les annotations 

La version 5 de Java introduit de nouveaux elements de langages dont les annotations 
font partie. Les versions precedentes ne les supportent pas, mais il est eventuellement 
possible d'utiliser le framework Commons Attributes d'Apache afin de mettre en ceuvre 
un mecanisme similaire. Spring supporte ces deux types de metadonnees incluses dans 
les sources. 

Spring offre la possibility de definir les comportements transactionnels des composants 
grace a des annotations Java 5. Ce mecanisme permet d'alleger le fichier XML de confi- 
guration de Spring et de specifier le comportement transactionnel aussi bien au niveau du 
contrat du composant que de son implementation. II est toutefois preferable de les definir 
au niveau du contrat du composant. 
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Spring permet de definir un comportement general pour une interface. Ses differentes 
methodes heritent de ce comportement par defaut mais peuvent le surcharger au cas par 
cas. Ce mecanisme est similaire entre l'interface et 1' implementation. Cette derniere peut 
surcharger les comportements au niveau de la classe et des methodes. 

Les types de comportements sont ajoutes dans les services metier (interface ou imple- 
mentation) grace a l'annotation Transactional. Le tableau 12.11 recapitule les differentes 
proprietes possibles pour cette annotation. 



Tableau 12.11 Proprietes de l'annotation Transactional 



Propriete 


Type 


Description 


Propagation 


enum:Propagation 


Specifie le type de propagation de la transaction. La 
valeur par defaut est PROPAGATI0N_REQUIRED. 


Isolation 


enum: Isol ation 


Specifie le niveau d'isolation de la transaction. La valeur 
par defaut est ISOLATION_DEFAULT. 


Readonly 


bool ean 


Specifie si la transaction est en lecture seule. La valeur 
par defaut est fal se. 


Rol 1 backFor 


Tableau d'objets de type CI ass 


Specifie la liste des exceptions qui causeront une annu- 
lation de la transaction. 


Rol 1 backForCl assname 


Tableau d'objets de type String 


Specifie la liste des exceptions qui ne causeront pas 
d'annulation de la transaction. 


NoRol 1 backFor 


Tableau d'objets de type CI ass 


Specifie la liste des exceptions qui ne causeront pas 
d'annulation de la transaction. 


NoRoll backForCl assname 


Tableau d'objets de type Stri ng 


Specifie la liste des exceptions qui ne causeront pas 
d'annulation de la transaction. 



Le code suivant donne un exemple de mise en ceuvre de l'annotation Transactional sur 
l'interface TodoListsManager : 

©Transactional 

public interface TodoListsManager { 

void createTodoList(TodoList todoList); 

©Transactional ( readOnly=true) 
TodoList findTodoList(String listld); 

TodoList unsecuredFindTodoListtString listld); 

void updateTodoList(TodoList todoList); 

void deleteTodoList(String listld); 

void addTodoListUser(String listld. String login); 

void deleteTodoListUser(String listld. String login); 

Document backupTodoList(TodoList todoList); 

void restoreTodoListtString restoreChoice, 

String listld, InputStream todoListContent) 

throws JDOMException, IOException; 

} 
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Les annotations permettent de specifier le comportement transactionnel, mais il faut 
toujours utiliser des proxy pour les appliquer. La configuration des annotations se 
realise au niveau du proxy ou de l'intercepteur POA de gestion des transactions grace a 
la propriete transact! onAttributeSource. Spring fournit une implementation specifique 
de l'interface Transact! onAttributeSource pour les annotations, AnnotationTransacti on- 
AttributeSource. 

L'extrait de configuration suivant montre comment le realiser avec la classe ProxyFacto- 
ryBean : 

<!-- Bean transactionnel cible --> 
<bean id="todol_istsManagerTarget" 

cl ass="tudu. service, impl .TodoLi stsManagerlmpl "> 
<property name="todol_i stDA0"> 
<ref bean="todoListDAO"/> 
</property> 

<property name="todoDAO"> 

<ref bean="todoDAO"/> 
<property name="userManager"> 

<ref bean="userManager"/> 
</property> 
</bean> 

<!-- proxy transactionnel sur la cible --> 

<bean id="todol_istsManager" parent="transactionProxy"> 

<property name="transactionManager"> 
<ref bean="transactionManager"/> 

</property> 

<property name="target"> 

<ref bean="todoLi stsManagerTarget"/> 
</property> 

<property name="transactionAttributeSource"> 
<bean class=" org. spring-framework, transact ion. 

annotation.AnnotationTransactionAttributeSource"/> 

</property> 
</bean> 

Approches personnalisees 

Les approches decrites precedemment peuvent ne pas convenir completement a une 
application en raison de leur integration a d'autres composants ou frameworks utilises 
dans 1' architecture. 

D'une maniere generale, le support standard des transactions de Spring suffit largement. 
Cependant, il peut se reveler utile de combiner plusieurs technologies pour en tirer le 
meilleur parti, notamment dans les cas suivants : 

• Le besoin d'uniformiser la demarcation transactionnelle conduit a utiliser une API 
generique. Spring fournit ce type d' API, mais cette derniere peut etre utilisee sans pour 
autant recourir a l'injection de dependances implementee dans Spring. 
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• Le souci de modularite des composants amene a vouloir externaliser les problemati- 
ques techniques induites par les transactions. L'utilisation de technologies d'intercep- 
tion des traitements telles que la POA permet d'atteindre ce but. Le choix du type de 
tisseur POA peut s'effectuer en fonction des besoins de 1' application et ne pas etre 
celui de Spring. 

• La specification de comportements transactionnels plus fins pour les composants tran- 
sactionnels peut etre realisee a l'assemblage ou au deploiement de maniere declarative 
afin d'offrir encore plus de flexibilite. La combinaison de technologies telles que les 
EJB ou Spring permet d'offrir cette fonctionnalite. 

II est done possible de combiner Spring avec d'autres technologies ou frameworks afin de 
repondre au plus pres aux besoins de 1' application, notamment les technologies EJB et POA. 

Combiner Spring et EJB 

Dans la communaute J2EE, il est parfois de bon ton de mettre en concurrence la techno- 
logie EJB et le framework Spring. Les auteurs de cet ouvrage estiment pour leur part que 
les deux peuvent etre utilises de maniere complementaire, car ils ne couvrent pas 
completement les memes domaines. 

Comme un contexte d' application de Spring peut etre embarque dans un EJB Session, il 
est possible d'obtenir un niveau de granularite plus fin dans celui-ci. Cela apporte en 
outre des avantages en terme de gestion des transactions. 

Si une CMT (Container Managed Transaction) est utilisee, les transactions des EJB 
seront gerees par le conteneur. Un contexte d' application de Spring peut etre embarque 
dans un EJB afin de gerer plus finement les comportements transactionnels des differents 
composants utilises par l'EJB. Comme, dans ce cas, JTA est utilise, le gestionnaire de 
transactions JtaTransactionManager de Spring doit etre utilise. 

Si une BMT (Bean Managed Transaction) est utilisee, les transactions peuvent etre 
gerees de la maniere souhaitee dans Spring, qui les controle completement. 

Combiner Spring et AspectJ 

Les concepteurs de 1' application peuvent ne pas vouloir utiliser le tisseur POA de Spring 
et choisir un tisseur statique tel qu' AspectJ. II est possible de developper un aspect 
AspectJ utilisant les API de gestion transactionnelle de Spring. II est a noter qu' AspectJ 
fournit non pas un mecanisme de gestion transactionnelle, mais un cadre propice a sa 
mise en place. 

Spring offre une integration avec AspectJ permettant de realiser de l'injection de depen- 
dances de composants tiers sur un aspect de type singleton. Dans notre cas, le gestion- 
naire de transactions ainsi que les comportements transactionnels desires pour les 
composants tisses peuvent etre injectes dans 1' aspect. Le code advice de 1' aspect a des 
lors la responsabilite d' utiliser les API de Spring et de definir les coupes sur les composants 
transactionnels. 

Comme Spring a en charge la gestion du contexte transactionnel, 1' aspect peut etre de 
type singleton, ce framework le stockant dans un Thread Local . 
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En resume 

Spring offre un mecanisme de gestion des transactions particulierement flexible, qui 
permet de repondre au mieux aux exigences des applications. Ce framework fournit en 
outre un mecanisme de gestion des transactions declaratif independant des conteneurs 
J2EE, aussi bien pour les transactions locales que globales. 

De ce fait, Spring n'impose pas l'utilisation du service transactionnel du serveur d' appli- 
cations, lequel s'appuie sur les transactions globales, sans l'interdire pour autant. II est 
done possible de l'utiliser a bon escient. 

Spring permet d'externaliser la gestion des transactions des composants. Ces derniers 
n'ont de la sorte pas conscience de la strategie transactionnelle qui va etre utilisee. Celle- 
ci estrealisee lors de 1' assemblage des composants dans les fichiers de configuration. Les 
composants sont de la sorte de plus en plus decouples des technologies et frameworks 
sous-jacents. Utiliser directement leurs API constituerait une bien mauvaise pratique 
puisque les composants seraient alors fortement lies a la technologie et done tres difficiles 
a faire evoluer. 

Le tableau 12.12 recapitule les avantages et inconvenients de Spring et des EJB pour la 
gestion des transactions. 

Tableau 12.12. Avantages et inconvenients de Spring et des EJB 
pour la gestion transactionnelle 

Inconvenient 

- Serveur d'applications J2EE avec un conteneur 
d'EJB necessaire 

- Utilisation des transactions globales obligatoire 
dans le cas d'une gestion par le conteneur 

- Solution peu flexible 

- Complexity deportee au niveau du fichier 
de configuration du conteneur leger 

- Notions de POA souhaitables 



Technologie Avantage 

EJB - Gestion des transactions au niveau 

des composants 

-Choix du niveau d'intrusivite de la mise en oeuvre 
(par programmation ou declarative) 

Spring - Gestion des transactions au niveau 

des composants 

-Choix du niveau d'intrusivite de la mise en ceuvre 
(par programmation ou declarative) 

- Solution tres flexible quant aux types 
de transactions, a leur configuration 

et a la gestion des exceptions 

- Utilisation possible en dehors d'un serveur 
d'applications 



Tudu Lists : gestions des transactions 

Pour notre etude de cas Tudu Lists, nous avons choisi de mettre en ceuvre l'approche au 
cas par cas fondee sur la classe TransactionProxyFactoryBean precedemment decrite. Cette 
utilisation est adaptee a notre application puisque nous n' avons que quatre composants 
services metier auxquels s' applique un comportement transactionnel. 
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Comme 1' application utilise Hibernate pour interagir avec la base de donnees, nous avons 
mis en ceuvre la classe HibernateTransactionManager du package org.springf ra- 
mework.orm.hibernate3, implementation de l'interface PI atformTransactionManager pour 
Hibernate 3.0. 

Cette classe s'appuie sur l'instance de la SessionFactory configuree, comme l'illustre le 
code suivant, tire du fichier applicationContext-hibernate.xml situe dans le repertoire 
WEB-INF : 

<bean id="sessionFactory" class="org.springframework.orm 

.hibernate3. Local Session Factory Bean" > 

(...) 
</bean> 

<bean id="transactionManager" class="org. spring-framework. orm 

.hibernate3.HibernateTransactionManager"> 
<property name="sessionFactory" ref="sessionFactory n /> 
</bean> 

La configuration transactionnelle utilise cette entite afin de specifier par declaration, dans 
le fichier applicationContext.xml du repertoire WEB-INF, les comportements transac- 
tionnels des composants. 

Ces comportements, qui doivent etre specifies pour tous les composants service metier de 
1' etude de cas, sont recapitules au tableau 12.13. 



Tableau 12.13. Composants services metier de I'etude de cas 



Composant 


Comportement transactionnel 




userManager 


- Methode create : PR0PAGATI0N_REQUIRED 

- Methode update : PR0PAGATI0N_REQUIRED 

- Methode delete : PR0PAGATI0N_REQUIRED 

- Autres methodes : PROPAGATION_REQUIRED et readonly 




todoLi stsManager 


- Methode create : PR0PAGATI0N_REQUIRED 

- Methode update : PROPAGATION_REQUIRED 

- Methode delete : PR0PAGATI0N_REQUIRED 

- Methode add : PROPAGATION_REQUIRED 

- Methode restore : PROPAGATION_REQUIRED 
-Autres methodes : PROPAGATION_REQUIRED et readonly 




todosManager 


-Methode create : PR0PAGATI0N_REQUIRED 

- Methode update : PR0PAGATI0N_REQUIRED 

- Methode delete : PR0PAGATI0N_REQUIRED 

- Methode completeTodo : PROPAGATION_REQUIRED 

- Methode reopenTodo : PR0PAGATI0N_REQUIRED 
-Autres methodes : PR0PAGATI0N_REQUIRED et readonly 




conf igurationManager 


- Methode update : PR0PAGATI0N_REQUIRED 

-Autres methodes : PR0PAGATI0N_REQUIRED et readonly 





Le code suivant illustre la configuration du comportement transactionnel du composant 
ayant pour identifiant userManager dans le fichier applicationContext.xml precedemment 
cite : 

<bean id="userManagerTarget" 

class="tudu. service. impl . UserManagerlmpl "> 
(...) 
</bean> 

<bean id=" userManager" cl ass=" org. spring-framework. transaction 

. interceptor. Transact ionProxy Factory Bean "> 
<property name= "trans act ionManager" ref=" transact!' onManager"/> 
<property name="target" ref="userManagerTarget"/> 
<property name=" transaction Attributes'^ 
<props> 

<prop key="create*">PROPAGATION_REQUIRED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="del ete*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 

Conclusion 

La gestion des transactions est une des problematiques les plus importantes et les plus 
complexes a mettre en oeuvre dans une application. Elle peut impliquer plusieurs ressour- 
ces transactionnelles fondees sur des technologies differentes, avoir a prendre en compte 
des acces concourants et savoir reagir aux erreurs ou aux pannes afin de garantir la cohe- 
rence des donnees. La mise en place de ces mecanismes au sein des applications est 
indispensable afin de garantir leur robustesse. 

Les types de transactions utilises doivent etre adaptes aux besoins de l'application. Par 
exemple, l'utilisation de transactions globales peut amener une complexite inutile si une 
seule ressource transactionnelle est utilisee. Des frameworks tels que Spring fournissent 
desormais des mecanismes permettant de gerer les transactions locales de maniere decla- 
rative. 

La mise en place des transactions dans les applications ne doit pas etre negligee, car il 
s'agit d'une problematique de conception a part entiere. Les differents concepts propres 
aux transactions decrits dans ce chapitre doivent etre appliques aux bons composants et 
les polluer le moins possible avec du code technique. Cette mise en place ne doit pas non 
plus etre realisee au detriment de la modularite ni de la flexibilite de l'architecture appli- 
cative. 

L'utilisation de mecanismes declaratifs pour specifier les comportements transactionnels 
doit etre privilegiee, de me me que le choix de frameworks ou de technologies offrant 
cette fonctionnalite. 
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Technologies 
d'integration 

Cette partie decrit les differentes technologies permettant d'integrer des applications 
Java/J2EE a des systemes d'information d'entreprise, systemes fondes sur une multi- 
tude de mecanismes de communication et de technologies heterogenes. 

Les technologies d'integration de Java/J2EE comportent deux grandes families. La 
premiere utilise les specifications J2EE JMS et JCA afin de communiquer de maniere 
synchrone ou asynchrone avec les systemes d'information d'entreprise par le biais de 
middlewares. La seconde s'appuie sur les technologies XML, par 1' intermediate de 
leurs supports dans Java/J2EE, afin d'echanger des informations contenues dans des 
messages normalises. Dans ce dernier cas, les systemes accedes doivent necessairement 
exposer leurs services selon des technologies XML, tels les services Web. 

Le chapitre 13 traite des mecanismes des technologies JMS, relative aux middlewares 
orientes message, et JCA, relative aux communications avec les systemes d'information 
d'entreprise. II decrit ensuite la facon dont Spring facilite 1' utilisation de ces technologies 
dans les applications Java/J2EE 

Le chapitre 14 se penche sur la facon d'utiliser XML afin d'integrer des systemes 
d'information heterogenes. Nous detaillons les differents supports du framework 
Spring permettant d'utiliser les technologies XML de maniere optimale dans les appli- 
cations Java/J2EE. 

Le chapitre 15 aborde les problematiques liees a la securite dans les applications Java/ 
J2EE ainsi que la facon dont Acegi Security, un framework de securite complet et inte- 
gre utilisant Spring, permet de les resoudre de fagon optimale. 
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Les applications Java/J2EE doivent s'integrer dans les systemes d'information des entre- 
prises, communement designes par le terme EIS et correspondant aux differentes appli- 
cations et infrastructures de stockage des donnees. L'objectif est de pouvoir reutiliser des 
services applicatifs existants et de minimiser les duplications de donnees dans differents 
systemes d'information. 

Cela passe par l'interaction entre des applications pouvant etre separees physiquement au 
sein de l'entreprise et utilisant des mecanismes ou des technologies heterogenes. Cette 
interaction peut vite devenir complexe, puisqu'il n'est pas toujours possible de les 
reecrire ou de les modifier. Or cette reecriture n'est pas forcement la meilleure solution 
pour les applications repondant aux besoins et fonctionnant correctement. Dans ce cas, 
l'interaction avec elles est la solution la plus appropriee. 

Cette interaction peut s'inserer dans differents types de traitements et mettre en oeuvre 
des mecanismes de communication complexes, synchrones ou asynchrones. Ce chapitre 
se penche sur les technologies et mecanismes fournis par J2EE afin d'integrer des appli- 
cations dans des systemes d'information d'entreprise par le biais des specifications JMS 
(Java Messaging Service) et JCA (Java Connector Architecture). La figure 13.1 schematise 
ces echanges. 

Nous verrons que Spring fournit des supports pour ces deux technologies afin d'alleger 
leur mise en ceuvre et leur integration au sein des applications Java/J2EE. 
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Figure 13.1 

Interactions entre les 
applications Java/J2EE 
et les applications 
d'entreprise 



Applications 
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Middlewares 



Moniteurs 
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Middlewares 
orientes messages 
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Les sections qui suivent detaillent les differentes technologies permettant aux applica- 
tions Java/J2EE de s'integrer aux applications d'entreprise, ainsi que les supports de 
Spring simplifiant leur utilisation. Nous commencons par presenter la technologie JMS, 
afin de mieux apprehender son support par Spring. Nous utilisons ensuite la meme approche 
pour la technologie JCA. 



La specification JMS (Java Messaging Service) 

La specification JMS vise a resoudre les preoccupations generates des messageries appli- 
catives avec Java. 

JMS adresse la problematique generale des MOM (Message-Oriented Middleware), ou 
middlewares orientes messages, en Java. Ces outils permettent en effet de faire 
communiquer des applications par l'intermediaire de messages applicatifs contenant 
diverses informations applicatives ou de routage reseau. 

Ces systemes garantissent la distribution des messages aux applications tout en fournis- 
sant des fonctionnalites de tolerance aux pannes, d'equilibrage de charge, d'evolutivite et 
de support transactionnel. lis utilisent a cet effet des canaux de communication, designes 
par le terme destination, qui peuvent etre utilises afin de mettre en oeuvre des mecanismes 
de communication asynchrones. 



Les fournisseurs JMS 

Chaque fabricant JMS propose une implementation de I'API JMS cliente permettant d'interagir avec le 
serveur JMS. Le fabricant JMS offre egalement un module serveur de gestion de messages, qui imple- 
mente le routage et la distribution des messages. Ces deux entites sont collectivement designees par le 
terme fournisseur JMS. Quelle que soit I'architecture utilisee par un fournisseur JMS, les parties logiques 
d'un systeme JMS sont identiques. Un fournisseur JMS correspond done a un middleware ayant la 
responsabilite de recevoir et de distribuer les messages applicatifs. II implemente a cet effet des mecanismes 
complexes, qui garantissent renvoi et la reception de ces messages. 
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La specification JMS adressant la messagerie applicative fournit un cadre generique 
pour envoyer et recevoir des messages de maniere synchrone et asynchrone. Elle four- 
nit de surcroit un niveau d' abstraction normalise afin d'interagir avec differents syste- 
mes de messagerie applicative, la plupart d'entre eux supportant desormais cette 
specification. On designe les systemes de messagerie applicative compatibles JMS par 
le terme fournisseurs JMS. 

JMS distingue deux domaines de messagerie. Le premier domaine, appele file, ou queue, 
correspond a une distribution point-a-point. Un message envoye sur un domaine de ce type est 
distribue une seule fois et a un seul observateur enregistre, comme l'illustre la figure 13.2. 
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Figure 13.2 

Mecanisme de distribution des messages pour le domaine file 



Le second domaine, appele sujet, ou topic, fonctionne sur le principe des listes de diffu- 
sion. Tous les observateurs enregistres sur le domaine recoivent le message envoye, 
comme l'illustre la figure 13.3. 
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Figure 13.3 

Mecanisme de distribution des messages pour le domaine sujet 
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Notons qu'une file ou un sujet est communement designee dans la technologie JMS par 
le terme destination. Ces entites sont representees par les interfaces Queue et Topi c, heritant 
toutes deux de l'interface Destination du package javax. jms. 

La specification JMS comporte deux versions majeures. La version 1.0.2, la plus 
ancienne, dissocie dans ses API les deux domaines de messagerie. Elle comporte toute- 
fois des limitations, notamment pour la gestion transactionnelle des messages. La 
version 1 . 1 adresse ces problemes en uniformisant et homogeneisant les differentes API. 
Dans la suite du chapitre, nous nous fondons sur cette version 1.1, qui est couramment 
utilisee dans les applications d'entreprise Java/J2EE. 



Interaction avec le fournisseur JMS 

L'interaction avec le fournisseur JMS se realise en plusieurs etapes : 

1. Creation de la fabrique de connexions. 

2. Recuperation d'une connexion a partir de la fabrique precedente. II est possible de 
specifier des proprietes pour la connexion, telles que l'identifiant du client. 

3. Creation d'une session a partir de la connexion. Au moment de cette creation, il est 
possible de definir des proprietes transactionnelles, ainsi que le type d'acquittement 
d'envoi des messages. 

La fabrique de connexion JMS est normalisee par l'intermediaire de l'interface Connec- 
tionFactory du package javax. jms. Son unique fonction est de creer des connexions pour 
un fournisseur JMS, comme le montre son code ci-dessous : 

public interface ConnectionFactory { 
Connection createConnection( ) ; 

Connection createConnection(String userName, String password); 

} 

La connexion JMS correspond a la connexion physique avec le fournisseur JMS. Cette 
entite est normalisee par l'intermediaire de l'interface Connection du package javax. jms. 
Sa creation necessite une authentification de la part de l'utilisateur. Elle offre la possibi- 
lite de creer une session d'utilisation permettant d'envoyer et de recevoir des messages, 
ainsi que de creer differents types de messages. 

II est possible de positionner un identifiant pour la connexion par l'intermediaire de sa 
methode setCl ientlD. Le code suivant donne la definition de cette entite : 

public interface Connection { 
void cl ose( ) ; 
(...) 

Session createSessiontboolean transacted, int acknowl edgeMode) ; 

String getCl i entlDC ) ; 

Excepti onListener getExceptionListenert ) ; 
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ConnectionMetaData getMetaDatat ) ; 

void setClientID(String clientID); 

void setExceptionListener(ExceptionListener listener); 

void startt ) ; 

void stop( ) ; 

} 

Notons la presence de l'interface ExceptionListener et de la methode setExceptionListe- 
ner de l'interface Connecti on, qui permettent d'enregistrer des observateurs et de recuperer 
les exceptions survenant lors de 1' utilisation de la connexion. 

Lorsqu'une connexion est creee, elle se retrouve en mode non actif et ne peut done rece- 
voir de messages. II est par contre possible d'envoyer des messages par 1' intermediate 
de l'entite MessageProducer, que nous decrivons plus loin dans ce chapitre. 

Les methodes start et stop de l'interface precedente permettent de changer ce mode. Une 
fois la methode start invoquee, l'application peut utiliser l'entite MessageConsumer, que 
nous decrivons egalement plus loin, afin de recevoir des messages. La methode close 
permet quant a elle de fermer la connexion avec le fournisseur JMS. 

Notons qu'une connexion JMS est thread safe et que plusieurs tils d'execution peuvent 
done utiliser la meme connexion simultanement, ce qui n'est pas le cas de la session 
decrite par la suite. 

La session JMS permet d'interagir directement avec le fournisseur JMS afin d'envoyer, 
de recevoir et de creer des messages. Cette entite est normalisee par l'interface Sessi on du 
package javax. jms. Au moment de sa creation, l'utilisateur peut specifier si elle doit etre 
transactionnelle ainsi que le type d' acquittement des messages. Le code suivant donne la 
definition de cette entite : 

public interface Session { 
(...) 

//Creation de consommateur de messages 

MessageConsumer createConsumertDestination destination); 

MessageConsumer createConsumertDestination destination, 

String messageSel ector) ; 
MessageConsumer createConsumertDestination destination, 

String messageSelector, boolean NoLocal); 

//Gestion des souscriptions durables 
TopicSubscriber createDurabl eSubscribert 

Topic topic, String name); 
TopicSubscriber createDurableSubscribertTopic topic. 

String name, String messageSelector, boolean noLocal); 
void unsubscribetString name); 

//Creation de producteur de messages 

MessageProducer createProducertDestination destination); 

//Creation de destinations 

Topic createTopictString topicName); 



Technologies d'integration 



Partie IV 



Queue createQueue(String queueName); 
TemporaryTopi c createTemporaryTopic( ) ; 
TemporaryQueue createTemporaryQueue( ) ; 

//Creation de messages 

TextMessage createTextMessaget ) ; 

TextMessage createTextMessage(String text); 

Message createMessaget ) ; 

ObjectMessage createObjectMessaget ) ; 

ObjectMessage createObjectMessage(Serializable object); 

BytesMessage createBytesMessaget ) ; 

MapMessage createMapMessage( ) ; 

StreamMessage createStreamMessage( ) ; 

//Proprietes de la session 
int getAcknowl edgeMode( ) ; 
boolean getTransactedt ) ; 

//Observateurs enregistres 

Message Li stener getMessageListener( ) ; 

void setMessagel_istener(Messagel_istener listener); 

//Gestion des transactions 
void commit ( ) ; 
void recoverO; 
void rollbackO; 

//Gestion de la session 

void cl ose( ) ; 

(...) 

} 

Dans la definition de l'interface precedente, nous remarquons plusieurs types de methodes. 
Ces dernieres correspondent aux fonctionnalites recapitulees au tableau 13.1. 



Tableau 13.1. Fonctionnalites de la session JMS 



Fonctionnalite 


Description 


Envoi de messages 


Permet de creer les entites necessaires a la reception de messages. 


Reception de messages 


Permet de creer les entites necessaires a remission de messages. 


Gestion des souscriptions durables 


Fournit des methodes afin de gerer les souscriptions durables a des sujets. Ces dernie- 
res permettent a un utilisateur de recevoir tous les messages JMS, y compris ceux 
publies pendant une periode ou celui-ci est inactif. 


Creation de destinations 


Permet de creer des destinations (file ou sujet) en dehors des outils d'administration du 
fournisseur. 


Creation de messages JMS 


Offre plusieurs methodes permettant de creer les differents types de messages supportes 
par la specification. Leur nom suit la regie create<TYPE>Message( ). 


Proprietes de la session 


Permet de recuperer les valeurs des proprietes transacted et acknowledgeMode 
correspondant respectivement aux proprietes transactionnelles et d'acquittement. 
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Tableau 13.1. Fonctionnalites de la session JMS (suite) 



Fonctionnalite 


Description 


Enregistrement d'un observateur JMS 


Permet I'enregistrement d'un observateur JMS afin de recevoir et de traiter les messages 
par I'intermediaire de la methode setLi stener. 


Gestion des transactions 


Offre deux methodes afin de finaliser une transaction JMS : commit en cas de succes et 
rol 1 back en cas d'annulation. 


Gestion de la session 


La methode cl ose permet de termer la session JMS. 



Le code suivant met en oeuvre ces differentes entites afin d'interagir avec un fournisseur 
JMS : 

ConnectionFactory connectionFactory=nul 1 ; 
Connection connection=null ; 
Session session=nul 1 ; 



try { 

connectionFactory=getConnectionFactory( ) ; 
connection=connectionFactory .createConnectiont ) ; 
connection. start( ) ; 

boolean transacted=false; 

i nt acknowl edgeMode=Sessi on . AUT0_ACKNOWLEDGE ; 

session=connection.createSession(transacted,acknowledgeMode) ; 
} catchtException ex) ( 

convertJmsException(ex) ; 
} finally { 

closeSession(session) ; 

stopAndCl oseConnecti on (connection) ; 



Constituants d'un message JMS 

Avant d'envoyer des informations au fournisseur JMS, il faut d'abord determiner le type 
de message puis le creer. Un message JMS est structure comme decrit au tableau 13.2. 



Tableau 13.2. Constituants d'un message JMS 


Constituant 


Description 


En-tete du message 


Permet de specifier des informations interpretables aussi bien par le client que par le 
fournisseur afin de definir le message et de I'acheminer. La plupart de ces en-tetes 
(JMSDesti nation, JMSDel i veryMode, JMSExpi ration, JMSPriority, JMSMessagelD, 
JMSTimestamp) sont positionnes automatiquement par les methodes send ou publ i sh 
de la session JMS. Seuls les en-tetes JMSCorrelationID, JMSReplyTo et JMSType 
peuvent etre utilises par I'application cliente. 


Proprietes du message 


Permet de specifier des informations applicatives dans le message. 


Corps du message 


Contient les donnees specifiques de I'application. Elles peuvent prendre differentes 
formes au sein de cette partie. 
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JMS definit plusieurs types de messages, comme indique au tableau 13.3. 



Tableau 13.3. Types de messages JMS 


Type 


Description 


StreamMessage 


Permet de stacker sequentiellement des informations de type primitif dans le message. 
Cette interface etend I'interface Message afin de fournir des methodes de lecture et 
d'ecriture de donnees par type. 


MapMessage 


Permet de stacker les informations du message sous forme de table de hachage. Cette 
interface etend I'interface Message afin de fournir les methodes permettant d'acceder 
aux differents elements suivant leurs types. 


TextMessage 


Permet de stacker des informations de type texte, aussi bien texte simple que XML, dans 
un message JMS. Cette interface etend I'interface Message afin de fournir des methodes 
getText et setText pour acceder au texte du message et le specifier. 


ObjectMessage 


Permet de stacker un objet Java serialisable dans un message JMS. Cette interface 
etend I'interface Message afin de fournir des methodes getObject et setObject pour 
acceder a I'objet du message et le specifier. 



BytesMessage Permet de stacker un tableau d'octets dans un message JMS. Cette interface etend 

I'interface Message afin de fournir des methodes pour lire et ecrire des octets. 



La creation des messages se realise a partir d'une instance de la session courante, comme 
le montre le code suivant : 

Session session = createSession(connection) ; 

//Creation d'un message de type texte 

TextMessage txtMessage = session .createTextMessage( ) ; 

message. setTextt "Le texte de mon message"); 

(...) 

//Creation d'un message de type Map 
MapMessage mapMessage = session. createMapMessaget ) ; 
mapMessage.setString( "description" , "Description de mon message"); 
mapMessage. setlntCtai lie" ,26) ; 

II est egalement possible de positionner des en-tetes et des parametres sur le message, 
comme dans le code suivant : 

txtMessage. set JMSCorrel ationID( "mon Id" ) ; 

txtMessage. setStringProperty( "maPropriete" , "maVal eur" ) ; 



Envoi de messages 

L'entite cle pour envoyer des messages avec JMS est I'interface MessageProducer du 
package javax. jms, dont le code est le suivant : 

public interface MessageProducer { 
void cl ose( ) ; 
int getDel iveryModef. ) ; 
Destination getDestination( ) ; 
boolean getDisableMessagelDO; 
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bool ean getDisabl eMessageTimestamp( ) ; 
int getPriority( ) ; 
long getTimeToLivet ) ; 

void send( Destination destination, Message message) ; 
void send(Destination destination, Message message, 

int del iveryMode, int priority, long timeToLive); 
void send(Message message) ; 
void send(Message message, int deliveryMode, 

int priority, long timeToLive) ; 
void setDel iveryModetint deliveryMode); 
void setDisableMessagelDtboolean value); 
void setDisableMessageTimestamp(boolean value); 
void setPriorityd'nt defaultPriority) ; 
void setTimeToLivedong timeToLive); 

} 

Une entire MessageProducer possede les proprietes decrites au tableau 13.4. 



Tableau 13.4. Proprietes de I'entite MessageProducer 



Propriete 


Description 


destination 


Destination (file ou sujet) sur laquelle le message doit etre envoye. 


del i veryMode 


Mode de distribution du message. Les valeurs possibles sont Del ivery- 
Mode. N0N_PERS I STENT et DeliveryMode. PERSISTENT. Le mode persistant garantit 
une distribution du message, meme en cas de panne du fournisseur JMS, ce qui n'est 
pas le cas en mode non persistant. 


disableMessagelD 


Deactivation de la generation d'identifiant de messages par le fournisseur JMS 


disabl eMessageTimestamp 


Deactivation du calcul de I'estampille temporelle par le client JMS 


priority 


Priorite du message 


timeToLi ve 


Date d'expiration du message 



Toutes ces proprietes peuvent etre specifiees de maniere globale au moment de la crea- 
tion du MessageProducer. Dans ce cas, les messages utilisent ces valeurs lors de leur expe- 
dition, comme dans le code suivant : 

(...) 

Session session = createSession(connection) ; 
Destination destination=getDestination( ) ; 
TextMessage message=session.createTextMessage( ) ; 
message. setText( "texte du message"); 
MessageProducer messageProducer 

= sessi on. createProducer( destination) ; 
messageProducer. setDel iveryMode(Message.DEFAULT_DELIVERY_MODE) ; 
messageProducer. setPriority( Message. DEFAULT_PRIORITY) ; 
messageProducer. setTimeToLi ve( Message. DEFAULT_TIME_TO_LIVE) ; 
messageProducer. send(message) ; 
messageProducer. close () ; 
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II est possible de definir des valeurs specifiques pour un message lors de son envoi. Ces 
dernieres remplacent les valeurs definies au niveau du MessageProducer, comme dans le 
code suivant : 

(...) 

Session session = createSession(connection) ; 
Destination destination=getDestination( ) ; 
TextMessage message=session.createTextMessage( ) ; 
message. setText( "texte du message"); 
MessageProducer messageProducer 

= session. createProducer(destination) ; 
messageProducer. send (message. Message. DEFAULT_DELIVERY_MODE. 

Message. DEFAULT_PRIORITY, 

Message. DEFAULT_TIME_TO_LIVE); 

messageProducer. closet) ; 



Reception de messages 

L'entite cle pour recevoir des messages avec JMS est l'interface MessageProducer du 
package javax. jms, dont le code est le suivant : 

public interface MessageConsumer ( 
void cl ose( ) ; 

Message Li stener getMessagel_istener( ) ; 
String getMessageSel ectort ) ; 
Message receiveO; 
Message receivedong timeout); 
Message recei veNoWaitt ) ; 

void setMessageLi stenertMessageLi stener listener); 

} 

Cette interface offre la possibility de recevoir des messages JMS de maniere synchrone, 
et done la plupart du temps bloquante, par l'intermediaire de ses differentes methodes 
receive. 

Ces methodes permettent de se mettre en attente d'un message indefiniment, durant un 
temps fini ou non bloquant. Dans ce dernier cas, la methode renvoie nul 1 si aucun message 
n'est disponible au moment de son execution. Le code suivant en donne un exemple 
d'utilisation : 

(...) 

Session session = createSession(connection) ; 
Destination destination=getDestination( ) ; 
MessageConsumer messageConsumer 

= session. createConsumer(destination) ; 

int timeout = 60; 

Message message = messageConsumer. receive(timeout) ; 
messageConsumer. closet) ; 
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Lorsque l'entite MessageConsumer est utilisee conjointement avec l'interface MessageListe- 
ner, elle permet de recevoir des messages JMS de maniere asynchrone. Dans ce cas, lors 
de la reception d'un message, la methode onMessage de l'observateur est appelee, avec le 
message en parametre. Le code suivant decrit l'interface MessageListener du package 
javax.jms : 

public interface MessageListener { 
void onMessagetMessage message); 

Voici un exemple de mise en ceuvre de reception asynchrone de message avec JMS : 
(...) 

Session session = createSession(connection) ; 
Destination destination=getDestination( ) ; 
MessageConsumer messageConsumer 

= sessi on. createConsumer( destination) ; 
MessageListener listener = new MyMessageListener( ) ; 
MessageConsumer. setMessageListenerd istener) ; 
Thread. sleep(60) ; 
messageConsumer. close () ; 



Versions de JMS 

JMS 1.0.2 fait la distinction entre les differents domaines de messagerie, entrainant de 
serieuses limitations dans la gestion des transactions et l'uniformisation des API de la 
technologie. 

La version 1 . 1 uniformise ces deux domaines mais reste compatible avec les API de la 
version precedente. De ce fait, la plupart des entites de la version 1.0.2 sont desormais 
des sous-classes des entites de la version 1.1. 

Le tableau 13.5 recapitule les differentes entites de ces deux versions de JMS. 



Tableau 13.5. Entites des versions 1.0.2 et 1.1 de JMS 



Entite JMS 1.1 


Entite JMS 1.0.2 (file) 


Entite JMS 1.0.2 (sujet) 


Connect! onFactory 


QueueConnecti onFactory 


Topi cConnect ion Factory 


Connection 


QueueConnection 


TopicConnection 


Session 


QueueSession 


TopicSession 


MessageProducer 


QueueSender 


Topi cPubl isher 


MessageConsumer 


QueueRecei ver 


TopicSubscriber 


Destination 


Queue 


Topi c 



J Technologies d'integration 

Support JMS de Spring 

Le support JMS de Spring, facilite 1' utilisation de cette technologie aussi bien pour son 
parametrage que pour son utilisation. 

Nous detaillons dans cette section la configuration des entites JMS, ainsi que la classe 
centrale du support et la facon dont le framework gere 1' envoi et la reception de messages 
JMS. 

Le support JMS de Spring concerne les versions 1.0.2 et 1.1, mais nous ne detaillons 
dans cet ouvrage que le support de cette derniere. 



Configuration des entites JMS 

La premiere chose a mettre en place afin d'utiliser les API de JMS est la fabrique de 
connexions. La plupart du temps, les fournisseurs JMS les rendent disponibles aux appli- 
cations clientes par le biais de JNDI. Ces entites doivent etre configurees prealablement 
par l'intermediaire d'outils d' administration. 

La classe JndiObjectFactoryBean peut etre mise en oeuvre afin de les utiliser, comme dans 
le code suivant : 

<bean id=" jmsConnect ion Factory" 

class="org. spring-framework, jndi . Jndi Object Factory Bean" > 
<property name="jndiName" value="myConnectionFactory"/> 
<property name=" jndi Envi ronment"> 

(...) 
</property> 
</bean> 

Notons qu'il est indispensable de specifier l'environnement JNDI associe au fournisseur 
JMS. Le support JMS laisse la possibilite de configurer la fabrique en tant que Bean. 

La deuxieme etape consiste a determiner les differentes destinations que 1' application 
utilise et la maniere dont elle y accede. Le support JMS definit l'abstraction Desti nati on- 
Resolver dans le package org. springframework. jms. support. destination dans le but de 
recuperer une instance a partir d'un nom par l'intermediaire de la methode resol veDesti - 
nationName decrite ci-dessous : 

public interface DestinationResolver { 

Destination resolveDestinationName(Session session, 

String destinationName, 
boolean pubSubDomain) 
throws JMSException; 

} 

Cette interface possede deux implementations, localisees dans le meme package que 
precedemment : Jndi DestinationResolver, qui resout le nom en utilisant JNDI, et Dynami- 
cDestinationResolver, qui utilise les methodes createQueue et createTopic de la session 
JMS afin de creer dynamiquement des files et des sujets JMS. Elles doivent etre utilisees 
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lorsque les differentes entites du support sont configurees avec des noms de destination et 
non des instances. 



ActiveMQ 

ActiveMQ est un fournisseur JMS Open Source particulierement leger et performant. Entierement ecrit en 
Java, il peut etre utilise en mode autonome ou embarque dans une application ou des tests unitaires. Ce 
projet est devenu recemment un sous-projet du projet Geronimo d'Apache, correspondant a une imple- 
mentation complete de J2EE. II est accessible a I'adresse http://www.activemq.org/. 



II est toujours possible d'utiliser l'entite JndiObjectFactoryBean afin de recuperer une 
instance de la destination, comme dans le code suivant pour le fournisseur JMS Acti- 
veMQ : 

<bean id="jmsQueue" 

cl ass="org.springf ramework. jndi . Jndi Object Factory Bean" > 
<property name=" jndi Name"Xval ue>queue</val ueX/property> 
<property name=" jndi Envi ronment"> 
<props> 

<prop key="java. naming. factory. initial "> 

org. act ivemq. jndi .ActiveMQInitialContextFactory 
</prop> 

<prop key="java. naming. provider. url "> 

tcp://localhost:61616 
</prop> 

<prop key=" queue. queue" >tudu.queue</prop> 
</props> 
</property> 
</bean> 

Le template JMS 

Le template JMS est la classe centrale du support JMS de Spring puisqu'elle facilite 
1' interaction entre le fournisseur JMS et 1' application. 

II existe deux versions de cette entite, correspondant aux differentes versions de la speci- 
fication JMS, mais nous ne detaillons que celle relative a la version 1.1. 

Ce template s'appuie sur une fabrique de connexions JMS et une destination configurees 
de la meme maniere que precedemment. Etant donne qu'il possede differentes proprietes 
de parametrage, il est recommande de le configurer dans Spring de la facon suivante : 

<bean id="jmsTemplate" 

cl ass= "org. springframework. jms. core. JmsTempl ate"> 

<property name=" connect ion Factory" ref ="jmsConnect ion Factory "/> 

<property name="" ref="destination" ref=" jmsQueue"/> 

(...) 
</bean> 

Le template peut etre configure en tant que singleton, puisqu'il se fonde directement sur 
une fabrique de connexions JMS, et etre injecte ensuite dans les composants de l'application. 
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Le tableau 13.6 recapitule les differents parametres de configuration du template JMS 
(classe JmsTempl ate). 



Tableau 13.6. Proprietes de la classe JmsTemplate 



Propriete 


Utilisation 


Description 


destinationResol ver 


Envoi et reception (par defaut null) 


Correspond a I'entite utilisee afin de recuperer Ins- 
tance de la destination dont le nom a ete confiqure par 
I'intermediaire de la propriete defaultDestination. 
Elle est de type DestinationResol ver. 


sessionTransacted 


Envoi et reception (par defaut f al se) 


Permet de determiner si les sessions JMS creees sont 
transactionnelles. 


sessionAcknowl edgeMode 


Envoi (par defaut 

Session .AUT0_ACKN0W LEDGE) 


Correspond au mode d'acquittement des messages 
envoyes. 


defaultDestination 


Envoi et reception (par defaut null) 


Correspond a la destination par defaut. Elle peut etre 
renseiqnee aussi bien avec I'instance de la destination 
qu'avec son nom. Cette propriete est utilisee par les 
methodes du template ne possedant pas d'informa- 
tion de destination en parametre. 


messageConverter 


Envoi et reception (par defaut null) 


Correspond a I'entite utilisee afin de construire un 
message a partir d'un objet et de recuperer un objet a 
partir d'un message. Elle est de type Message- 
Converter et est decrite a la section suivante. 


messageldEnabl ed 


Envoi (par defaut true) 


Determine si la generation des identifiants des mes- 
sages JMS estactivee. 


messageTimestampEnabl ed 


Envoi (par defaut true) 


Determine si la generation des estampilles temporelles 
des messages JMS est activee. 


pubSubNoLocal 


Envoi et reception (par defaut f al se) 


Est necessaire pour ce template afin d'utiliser la creation 
dynamique de destinations. 


receiveTimeout 


Reception (par defaut -1) 


Correspond au temps d'attente de reception de messa- 
ges. Si sa valeur est superieure ou egale a 0, cette pro- 
priete est passee en parametre de la methode recei ve 
de la session JMS. Dans le cas contraire, la methode 
recei ve est bloquee jusqu'a I'arrivee d'un message. 


expl ici tQosEnabl ed 


Envoi (par defaut false) 


Permet d'activer I'utilisation des parametres deli ve- 
ryMode, priority et timeToLive lors de I'envoi de 
messages JMS. Si la valeur de cette propriete est 
true, les proprietes precedentes sont passees en 
parametres de la methode send de la session JMS. 


del 1 veryMode 


Envoi (par defaut 

Message. DEFAULT_DE LI VERY_M0DE) 


Correspond au mode de distribution des messages 
envoyes. 


priority 


Envoi (par defaut 

Message. DEFAULT_PRIORITY) 


Correspond a la priorite des messages envoyes. 


timeToLive 


Envoi (par defaut 

Message. DEFAULT_TIME_TO_LIVE) 


Correspond a la configuration de la date d'expiration 
des messages envoyes. 



Ces parametres peuvent etre specifies sur I'instance du template grace aux fonctionnalites 
de Spring relatives a l'injection de dependances. 
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Envoi de messages 

La classe JmsTemplate facilite l'envoi de messages au fournisseur JMS en integrant toute 
la manipulation des API JMS, tout en laissant la possibilite au developpeur de specifier 
les parties propres a son application. 

Ann d' envoy er des messages JMS, le template permet de travailler directement sur des 
ressources JMS qu'il gere par le biais de methodes de rappel, et ce aux niveaux a la fois 
de la session et du producteur. II s'appuie pour cela sur les interfaces SessionCallback et 
ProducerCal 1 back. 

L'interface SessionCallback met a disposition la session grace a la methode dolnjms, 
comme ci-dessous : 

public interface SessionCallback { 

Object doInJmstSession session) throws JMSException; 

) 

L'interface ProducerCal 1 back enrichit cette signature de methode afin de rendre disponible 
le producteur de message, comme ci-dessous : 

public interface ProducerCal 1 back { 
Object doInJmstSession session, 



Le template JMS utilise ces interfaces par 1' intermediate de methodes execute de la 
maniere suivante : 

Final Destination destination = getDestination( ) ; 
JmsTemplate template = getJmsTempl ate( ) ; 
template. execute(new ProducerCal 1 back( ) { 
public Object doInJmstSession session, 



} 

1); 

Creation et envoi de messages 

Le template JMS peut etre parametre avec une implementation de l'interface Message- 
Creator du package org. springframework. jms. core afin de specifier la facon de creer le 
message a envoyer. Le code suivant donne sa definition : 



MessageProducer producer) throws JMSException; 



MessageProducer producer) throws JMSException { 
TextMessage message = session .createTextMessaget ) ; 
message. setTextC'Le texte du message."); 
producer .send (destination .message) ; 



public interface MessageCreator { 

Message createMessage(Session session) throws JMSException; 
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Ce mecanisme peut etre mis en oeuvre avec toutes les methodes send du template JMS 
possedant un parametre de type MessageCreator, comme ci-dessous : 

JmsTemplate template = getJmsTempl ate( ) ; 
template. sendtnew MessageCreator( ) { 

public Message createMessage(Session session) 

throws JMSException { 
TextMessage message = session. createTextMessage( ) ; 
message. setTextCLe texte du message."); 
return message; 

} 

} 

Conversion et envoi de messages 

Le support JMS de Spring fournit l'interface MessageConverter dans le package 
org. springframework. jms. support. converter afin de generaliser le mecanisme precedent a 
la reception (conversion d'un message en objet) et a l'envoi (conversion d'un objet en 
message) de messages. 

Contrairement au createur, un convertisseur de messages est global au template JMS. Son 
code est le suivant : 

public interface MessageConverter { 

Message toMessage(Object object. Session session) 

throws JMSException, MessageConversionException; 
Object f romMessage(Message message) 

throws JMSException, MessageConversionException; 

} 

L'utilisateur doit specifier dans une classe la facon de passer d'un message a un objet, et 
inversement. Le code suivant decrit son utilisation avec des messages de type TextMes- 
sage : 

public MonConverti sseur implements MessageConverter { 

public Message toMessage(Object object. Session session) 

throws JMSException, MessageConversionException { 
TextMessage message = session. createTextMessage( ) ; 
if( object instanceof String ) { 

message. setText( (St ring) object) ; 
} else { 

message. setText(object.toString( ) ) ; 

} 

return message; 

} 



public Object f romMessage(Message message) 

throws JMSException, MessageConversionException { 
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if( message instanceof TextMessage ) { 

return ( (TextMessage)message) .getTextt ) ; 
} else { 

throw new MessageConversionException( 

"Type de message non supporte."); 

} 

} 

Cette implementation est rattachee au template precedent de la maniere suivante : 
<bean id="jmsMessageConverter" cl ass="MonConverti sseur"/> 

<bean id="jmsTemplate" 

class="org.springframework. jms.core. JmsTempl ate"> 

<property name="messageConverter" ref=" jmsMessageConverter"/> 

(...) 
</bean> 

Ce mecanisme peut etre mis en oeuvre avec toutes les methodes convertAndSend du 
template JMS, comme ci-dessous : 

JmsTempl ate template = getJmsTempl ate( ) ; 
template. convertAndSendC'Le texte du message."); 

Notons que ce code utilise le convertisseur configure precedemment sur le template JMS. 
Postprocessing des messages 

L' envoi de messages avec conversion offre la possibilite de realiser des traitements sur 
les messages immediatement avant qu'ils soient envoyes. Ce mecanisme se fonde sur 
l'interface MessagePostProcessor suivante du package org. spring-framework, jms.core : 

public interface MessagePostProcessor { 

Message postProcessMessagetMessage message) 

throws JMSException; 

} 

L'exemple suivant decrit une mise en oeuvre possible de cette entite afin d'ajouter auto- 
matiquement un identifiant de correlation a chaque message envoye : 

OmsTemplate template = getJmsTempl ate( ) ; 
template. convertAndSendC'Le texte du message.", 
new MessagePostProcessor( ) { 
public Message postProcessMessagetMessage message) 

throws JMSException { 
String correlations = getCorrel ationldt ) ; 
message. set JMSCorrel ationID(correl ationld) ; 

} 

}); 
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Reception de messages 

Le support JMS de Spring permet de recevoir des messages JMS aussi bien de maniere 
synchrone qu'asynchrone. La mise en oeuvre de ces fonctionnalites se fonde sur des entites 
differentes, dont certaines sont apparues avec la version 2.0 du framework. 

La reception synchrone implique une action de 1' application cliente JMS afin de recupe- 
rer les messages, action pouvant etre bloquante. Cette fonctionnalite utilise la classe 
centrale du support JMS, a savoir la classe JmsTempl ate. 

La reception asynchrone met en ceuvre des observateurs JMS. Le support JMS fournit un 
cadre, denomme conteneur de gestion des observateurs, afin d'enregistrer ces observateurs 
aupres des ressources JMS appropriees. 

Reception synchrone de messages 

Puisque le support JMS offre la possibilite de travailler sur une session geree par le 
template par l'intermediaire de l'interface SessionCallback, il est possible de creer une 
instance de MessageConsumer afin de recevoir des messages. 

Notons que Spring ne definit pas d'interface ConsumerCal 1 back, a la maniere de l'interface 
ProducerCallback. La mise en ceuvre de l'interface SessionCallback n'est pas recomman- 
dee dans ce cas, car le developpeur a la responsabilite de gerer 1' instance de consommation 
des messages. Le template JMS fournit des methodes afin d'encapsuler toute cette logique 
technique. 

Comme pour 1' envoi de messages, la reception se decompose en deux parties, dont la 
premiere recupere directement le message recu. Elle s'appuie pour cela sur les methodes 
receive et receiveSelected. Cette derniere offre la possibilite d'utiliser un selecteur de 
message afin de cibler les messages desires. Le code suivant en donne un exemple d' utili- 
sation : 

I JmsTempl ate template = getJmsTempl ate( ) ; 
Message message = tempi ate. receive( ) ; 

Notons que la methode receive de cet exemple utilise tous les parametrages du template 
realises precedemment. 

La seconde methode permet d'utiliser le mecanisme de conversion aborde lors de 1' envoi 
de message, toutes les methodes nominees receiveAndConvert et recei veSel ectedAnd- 
Convert mettant en oeuvre ce mecanisme. 

Ce dernier type de methode offre la possibilite d'utiliser un selecteur de message afin de 
cibler les messages desires. Le code suivant en donne un exemple d' utilisation : 

JmsTempl ate template = getJmsTempl ate( ) ; 

String txtMessage = (String)template.receiveAndConvert( ) ; 

Notons que la methode receive de cet exemple utilise egalement tous les parametrages 
realises precedemment sur le template ainsi que sur le convertisseur MonConverti sseur. 
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Reception asynchrone de messages 

A partir de la version 2.0 de Spring, le support JMS integre un cadre robuste afin de 
mettre en oeuvre des mecanismes de reception asynchrones de JMS. Spring implemente 
pour cela deux approches. La premiere utilise l'entite MessageConsumer et sa methode 
setLi stener, et la seconde l'entite ServerSessi on. 

Ces deux approches ont en commun les proprietes recapitulees au tableau 13.7. 



Tableau 13.7. Proprietes communes des conteneurs JMS de Spring 



Propriete 


Description 


destinationResolver 


Correspond a l'entite utilisee afin de recuperer I'instance de la destination dont le 
nom a ete configure par I'intermediaire de la propriete defaultDestination. 
Elle est de type DestinationResol ver. 


connecti onFactory 


Correspond a la fabrique de connexions a utiliser. 


sessionTransacted 


Permet de determiner si les sessions JMS creees sont transactionnelles. 


sessionAcknowl edgeMode 


Correspond au mode d'acquittement des messages envoyes. 


messageSel ector 


Correspond a l'entite utilisee afin de filtrer les messages a recevoir. 


messageLi stener 


Correspond a I'instance de I'observateur JMS utilise. 


expose Li stener Session 


Permet de specifier si la session a fournir aux observateurs JMS de type Sessi o- 
nAwareMessageLi stener est celle utilisee pour la reception des messages. 


autoStartup 


Specifie si la methode start de la connexion JMS doit etre appelee au charge- 
ment du conteneur. Si sa valeur est f al se, il est possible de le demarrer ulterieu- 
rement avec la methode start du conteneur. L'arret de la reception des 
messages est realise avec la methode stop. 


destination 


Correspond a la destination a utiliser. Elle peut etre renseignee avec I'instance de 
la destination ou son nom. 



Le premier conteneur JMS de Spring est implemente par I'intermediaire de la classe 
SimpleMessageListenerContainer du package org . springf ramework. jms . 1 i stener. Cette 
classe correspond a la forme la plus simple et offre une approche multithreadee. 

II est possible de parameter le nombre de sessions utilisees pour la reception des messa- 
ges par I'intermediaire de la propriete concurrentConsumers. Ce conteneur ne permet pas 
de modifier dynamiquement sa configuration au cours de 1' execution. Le code suivant 
donne un exemple de sa mise en oeuvre : 

<bean id="connectionFactory" 

cl ass=" org. act ivemq. Act i veMQConnecti on Factory "> 
<property name="brokerURL" value="tcp://localhost:61616"/> 
</bean> 
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<bean id="asynchTuduJms Li stener" 

cl ass="tudu.jms. AsynchTuduJmsLi stener"/> 

<bean id="jmsContainer" class="org.springframework.jms 

.1 i stener .Simpl eMessageLi stenerContainer"> 
<property name="connectionFactory" ref="connectionFactory"/> 
<property name="destinationName" value="tudu.queue"/> 
<property name="messageLi stener" ref="asynchTuduJmsLi stener"/> 

</bean> 

Le second conteneur, implements par 1'intermediaire de la classe ServerSessionMessage- 
ListenerContainer du meme package, est beaucoup plus evolue. II se fonde sur les API 
JMS ServerSessionPool , generalement mises en oeuvre par les serveurs d' applications. II 
permet de realiser la reception de messages de maniere multithreadee et se configure de 
la meme maniere que le precedent. 

En resume 

Le support JMS de Spring reduit la complexite liee a l'utilisation de cette technologie. 
II permet de configurer facilement les differentes entites de JMS dans le conteneur 
leger et de se fonder sur une entite principale gerant les interactions avec le fournisseur 
JMS. 

Le support offre egalement, a partir de la version 2.0, une facon elegante et simple de 
mettre en oeuvre des observateurs JMS afin d'utiliser les mecanismes asynchrones 
de communication. 

La specification JCA (Java Connector Architecture) 

Cette section se penche sur les preoccupations generates des interactions avec les syste- 
mes d' information d'entreprise ainsi que sur les concepts de la specification JCA visant a 
les resoudre avec Java. 

La specification JCA definit les mecanismes permettant d'acceder de maniere unifor- 
misee a des systemes d'information d'entreprise heterogenes. Ces derniers peuvent 
utiliser diverses technologies, dont Java/J2EE, et correspondre, par exemple, a des 
moniteurs transactionnels pour mainframes (CICS, IMS) ou a des ERP (SAP, People- 
soft, etc.). 

La specification JCA comprend deux versions : 

• Version 1.0. Adresse la fafon d'interagir avec des systemes d'information d'entreprise 
par 1'intermediaire de requetes tout en recourant aux services J2EE. Elle standardise une 
API cliente, appelee Common Client Interface, afin d'interagir avec ses systemes 
d'une maniere similaire a JDBC mais plus generique. 
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• Version 1.5. Enrichit la version precedente avec le support des connexions 
entrantes sur les connecteurs. Les systemes d'information peuvent envoyer des 
messages au connecteur, lequel notifie les observateurs enregistres. Cet ajout est 
fortement lie a la specification JMS permettant de normaliser ses interactions avec 
les services J2EE. 

L'objectif de la specification est egalement de standardiser les interactions entre les 
connecteurs et un fournisseur de services. Nous faisons ici la distinction entre fournisseur 
de services et serveur d' applications, puisque les deux ne sont pas forcement equivalents. 
Un serveur d' applications correspond a un fournisseur de services, mais la reciproque 
n'est pas verifiee. 

Les mecanismes de JCA peuvent etre utilises afin de faire interagir des ressources Java/ 
J2EE avec des services tels qu'un gestionnaire de transactions compatible JTA. 

La specification n'impose pas l'API cliente a utiliser, celle-ci etant determinee par 
1' implementation du connecteur. Ce dernier peut necessiter l'utilisation de Common 
Client Interface, comme c'est le cas pour des connecteurs tels que ceux d'IBM, permet- 
tant d'acceder a des mainframes via CICS ou IMS, mais peut egalement permettre la 
configuration de fabriques de connexions ou de sessions, telles que celles de JDBC, JMS 
ou Hibernate. 

La technologie JCA est de plus en plus utilisee dans les serveurs d' applications afin de 
configurer les differentes ressources qu'ils utilisent et de les faire interagir avec leurs 
services. Geronimo, par exemple, le serveur J2EE de la fondation Apache, configure 
les pools de connexions JDBC a partir de JCA et de son connecteur generique, 
TranQL. 

La specification JCA comporte deux parties distinctes : 

• Partie cliente. Utilisable dans les applications Java/J2EE afin d' interagir avec les 
systemes d'information d'entreprise. 

• Partie fournisseur de services. Utilisable par les serveurs applications ou les 
frameworks afin de configurer l'environnement d'execution de JCA aussi bien pour 
les communications sortantes qu'entrantes. 



Gestion des communications sortantes 

JCA offre un cadre afin de configurer la fabrique de connexions ou de sessions de diffe- 
rents frameworks ou technologies. Le connecteur a la responsabilite de travailler sur 
les connexions ou sessions physiques et fournit a 1' application cliente des connexions 
logiques. 

Ce mecanisme permet de realiser des interceptions de traitements afin d'inserer des 
fonctionnalites transversales de maniere transparente, telles que les transactions et la 
securite. 
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La figure 13.4 illustre les differentes interactions entre le connecteur et l'application ainsi 
que celles avec le fournisseur de services. 
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Figure 13.4 

Interactions du connecteur avec l'application et le fournisseur de services 



Sur cette figure, les differentes entites manipulees par l'application peuvent etre aussi 
bien celles de l'API Common Client Interface de JCA que celles d'autres technologies 
ou frameworks, tels que JDBC, JMS ou Hibernate. De plus, le fournisseur de services 
peut aussi bien etre un serveur d' applications que des composants autonomes. 

Le connecteur peut fonctionner en mode autonome, sans utiliser de fournisseur de servi- 
ces. Dans ce cas, il utilise son gestionnaire de connexions interne mais ne peut plus alors 
utiliser les transactions globales. 

L' implementation de l'interface ManagedConnectionFactory doit dans ce cas etre instanciee 
explicitement par l'application arm d' avoir acces a la fabrique, comme dans le code 
suivant : 

ManagedConnectionFactory managedConnecti on Factory 

= createAndConfigureManagedConnectionFactory( ) ; 
Object connectionFactory 

= managedConnectionFactory.createConnectionFactory( ) ; 

Notons l'existence de la methode createConnecti on Factory, possedant un parametre de 
type Connecti onManager, qui permet de specifier un gestionnaire de connexions pour le 
connecteur. Elle permet ainsi d'utiliser le connecteur avec un fournisseur de services tel 
que Jencks. Dans ce cas, l'utilisation des transactions globales est envisageable. 

JCA est souvent utilise pour configurer des fabriques de connexions ou de sessions afin de 
les faire participer a des transactions globales, la specification normalisant cette interaction 
quelle que soit la technologie employee. 
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Jencks 

Ce projet permet de configurer le gestionnaire de transactions JTA et le conteneur JCA du serveur 
d'applications Geronimo de maniere autonome dans n'importe quelle application Java/J2EE, application 
n'ayant plus la necessite d'utiliser un serveur d'applications J2EE complet. II est des lors possible d'utiliser 
les technologies JTA et JCA dans des applications Java autonomes ou dans des applications Web 
deployees dans Tomcat. Ce projet est en marge du support JCA de Spring et du fournisseur JMS Acti- 
veMQ. II est disponible a I'adresse http://jencks.org/. 



L'API Common Client Interface permet aux applications Java/J2EE d'interagir avec des 
systemes d' information d'entreprise selon les etapes suivantes : 

1. Creation de la fabrique de connexions. 

2. Recuperation d'une connexion a partir de la fabrique precedente. Elle est parametree 
par l'intermediaire d'une implementation de la classe ConnectionSpec relative au 
connecteur. 

3. Creation d'une interaction a partir de la connexion precedente. 

4. Execution de la requete, qui peut etre parametree par le biais d'une implementation 
de la classe InteractionSpec relative au connecteur. Les parametres ainsi que les 
retours sont decrits par des implementations de la classe Record et de ses derivees. 

Notons que les interfaces ConnectionSpec et InteractionSpec sont des classes marqueurs 
ne definissant aucune methode. 

La fabrique de connexions JCA est normalisee par l'intermediaire de l'interface Connecti on- 
Factory du package j a vax. resource. Son unique fonction est de creer des connexions pour un 
systeme d'information d'entreprise, comme le montre le code suivant de l'interface : 

public interface ConnectionFactory { 
Connection getConnection( ) ; 

Connection getConnection(ConnectionSpec properties); 
ResourceAdapterMetaData getMetaData( ) ; 
RecordFactory getRecordFactoryt ) ; 

} 

La connexion correspond a l'entite de communication avec le systeme. Sa creation peut 
etre parametree par l'intermediaire d'une implementation de ConnectionSpec du connec- 
teur, lequel permet, de maniere classique, de specifier des parametres d'authentification 
afin d'etablir la connexion. 

Le code suivant donne la definition de cette entite : 

public interface Connection { 
void closet); 

Interaction createlnteractiont ) ; 
Local Transaction getLocalTransactiont ) ; 
ConnectionMetaData getMetaDatat ) ; 
ResultSetlnfo getResultSetlnfot ) ; 

} 
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Cette entite offre un support afin de demarquer les transactions locales en rendant acces- 
sible une implementation de l'interface Local Transaction pour le connecteur. 

L'interaction permet d'executer une requete vers le systeme. Elle offre deux approches a 
cet effet, dont une seule est supportee par les connecteurs. La premiere consiste a passer 
les parametres d'entree sous forme de Record et de recuperer les resultats sous la meme 
forme. La seconde attend en parametres un premier Record contenant les parametres 
d'entree et un autre Record rempli suite a l'execution avec les parametres de retour. 

Le code suivant donne la definition de cette entite : 

public interface Interaction { 
void cl earWarnings( ) ; 
void cl ose( ) ; 

Record executednteractionSpec ispec, Record input); 
boolean executednteractionSpec ispec, 

Record input, Record output); 
Connection getConnectionO; 
ResourceWarning getWarnings( ) ; 

} 

La mise en oeuvre de ces differentes entites afin d'interagir avec un systeme d'information 
d'entreprise avec la premiere approche se deroule de la facon suivante : 

Connection connection = null; 
Interaction interaction = null; 

try { 

ConnectionFactory connectionFactory = getConnectionFactoryt ) ; 

ConnectionSpec connectionSpec = createConnectionSpect ) ; 
connection = connectionFactory. getConnection(connectionSpec) ; 

interaction interaction = connection. createInteraction( ) ; 
InteractionSpec interactionSpec = createlnteractionSpecO; 
Record inputRecord = createlnputRecordt ) ; 
Record outputRecord = interaction. execute( 

interactionSpec, inputRecord); 

(...) 

} catch(Exception ex) { 

convertResourceException(ex) ; 
} finally { 

closelnteracti on (interaction) ; 

closeConnecti on (connection) ; 

} 



Gestion des communications entrantes 

Comme nous l'avons vu precedemment, la version 1.5 de JCA enrichit la specification 
avec le support des communications entrantes. Le systeme d'information d'entreprise 
peut rappeler le connecteur afin de lui envoyer des messages. Ce mecanisme est souvent 
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utilise conjointement avec la specification JMS et trouve toute son utilite avec les outils 
de messagerie asynchrone tels que les fournisseurs JMS. 

La figure 13.5 illustre les differentes interactions entre le connecteur et l'application ainsi 
que celles avec le fournisseur de services. 
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Figure 13.5 

Interactions du connecteur avec l'application et le fournisseur de services 



La specification definit l'interface ResourceAdapter decrivant le connecteur et permettant 
d'enregistrer des points d'acces, materialises par des implementations de l'interface 
ActivationSpec. Le connecteur doit avoir ete prealablement demarre et initialise avec des 
entites du fournisseur de services et arrete a la fin de son utilisation. 

Le code suivant fournit les differentes methodes de l'interface ResourceAdapter : 

public interface ResourceAdapter { 
(... 

//Enregistrement et desenregistrement de points d'entree 
void endpointActi vat ion (MessageEndpointFactory endpoint Factory, 

ActivationSpec spec); 

void endpointDeactivation( 

MessageEndpointFactory endpoi nt Factory , 

ActivationSpec spec); 
//Demarrage et arret du connecteur 
void starttBootstrapContext ctx); 
void stop( ) ; 

} 
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Lors de l'activation d'un point d'acces, 1' implementation de l'interface ResourceAdapter 
utilise la fabrique MessageEndpointFactory afin d'instancier une unite de traitement de 
type MessageEndpoint. Cette entite met en oeuvre les mecanismes transactionnels en se 
fondant sur le cycle de vie du traitement : avant la reception d'un message (bef oreDel i - 
very), apres sa reception (afterDel ivery) et au moment de la finalisation du traitement 
(rel ease). 

Nous constatons que cette partie de JCA offre des similitudes avec la reception asyn- 
chrone de messages de la specification JMS, tout en fournissant un cadre plus generique. 
Dans le cas de l'utilisation de fournisseurs JMS, les MessageEndpoint peuvent etre relies a 
des observateurs JMS, lesquels seront notifies lors de la reception de messages. Nous 
verrons par la suite comment le framework Jencks permet de mettre en ceuvre cette 
fonctionnalite. 



Support JCA de Spring 

L'objectif du support JCA de Spring est de faciliter l'utilisation de 1' API Common Client 
Interface, ainsi que la configuration des connecteurs en mode non manage, et en dehors 
des serveurs d' applications, et celle des communications entrantes asynchrones. 

Dans le cas des communications sortantes, le support JCA reprend les concepts du 
support JDBC de Spring en l'adaptant a l'API Common Client Interface. II integre dans 
le framework la manipulation de ses entites tout en s'integrant avec le support transac- 
tionnel du framework. 

Le support JCA n'implemente pas actuellement les communications entrantes. Jencks 
offre cependant cette fonctionnalite en s'appuyant sur le framework Spring. 



Communications sortantes 

Le framework Spring integre, a partir de sa version 1.2, un support complet de la partie 
relative aux connexions sortantes permettant d'envoyer des requetes vers des systemes 
d'information d'entreprise en utilisant l'API Common Client Interface. 

Afin de decrire ce support, nous utilisons le connecteur Bl ackBox, disponible dans le SDK 
de J2EE. Nous avons retravaille le code de ce connecteur afin de le rendre davantage 
parametrable au niveau de la specification du pilote JDBC et de la requete SQL utilises. 
Le code modifie ainsi que le fichier jar correspondant sont disponibles dans 1' etude de 
cas Tudu Lists. 

Comme indique precedemment, un connecteur peut etre configure de deux manieres. La 
premiere consiste a le deploy er dans un serveur d' applications afin de rendre disponible 
par le biais de JNDI une instance de la fabrique de connexions correspondante. 

Dans ce cas, aucune configuration particuliere n'est necessaire pour le connecteur. 
L' application doit se fonder sur une instance de la fabrique en utilisant son support JNDI 
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par l'intermediaire de la classe JnidObjectFactoryBean de Spring, comme dans le code 
suivant : 

<bean id="connectionFactory" 

cl ass="org.springf ramework. jndi . Jndi Object Factory Bean" > 
<property name=" jndi Name" value="eis/monConnecteur"/> 
<property name=" jndi Envi ronment"> 

(...) 
</property> 
</bean> 

II est egalement possible de configurer un connecteur en dehors d'un serveur d'applica- 
tions dans une application. Pour ce faire, il convient d'instancier explicitement l'imple- 
mentation de l'interface ManagedConnectionFactory du connecteur puis d'utiliser le 
support de la classe Local Connecti onFactoryBean du package org.springfra- 
mework. jca. support afin de configurer une instance de la fabrique de connexions, comme 
dans le code suivant : 

<!-- Fabrique de connexion interne au connecteur --> 

<bean id="managedConnectionFactory" class="com. sun. connector 

. ccibl ackbox.Cci Local TxManagedConnect ion Factory "> 
<property name=" connect ionURL" 

val ue="jdbc:mysql : //I ocal host :3306/tudu"/> 
<property name="driverName" val ue="com.mysql . jdbc. Dri ver"/> 
</bean> 

<!-- Fabrique de connexion associee --> 

<bean id="connectionFactory" class="org.springframework.jca 

.support . Local Connect ion Factory Bean" > 
<property name="managedConnecti on Factory" 
ref="managedConnect ion Factory "/> 

</bean> 

II est possible d'utiliser le connecteur en mode manage hors d'un serveur d' applications 
en injectant une instance d'un gestionnaire de connexions JCA par l'intermediaire de la 
propriete connecti onManager. Le projet Jencks offre un support afin de configurer facile - 
ment dans Spring le gestionnaire de connexions JCA ainsi que le gestionnaire de transactions 
de Geronimo de maniere autonome. 

Avec ces deux approches, nous pouvons configurer avec JCA des fabriques de 
connexions de connecteurs. II est important de bien comprendre que ces fabriques ne 
sont pas necessairement compatibles avec l'API cliente CCI. En effet, il est possible 
de configurer une DataSource JDBC ou une SessionFactory d'Hibernate de cette maniere, 
a condition de posseder le connecteur correspondant. Puisque JCA normalise les interac- 
tions avec les gestionnaires de transactions JTA, cette approche permet de rendre des 
fabriques de connexions facilement compatibles XA afin de les faire participer a des tran- 
sactions globales (pour plus d' informations a ce sujet, voir le chapitre 12, relatif a la 
gestion des transactions). 
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Support de I'API Common Client Interface 

Spring offre un support de la partie cliente normalised, Common Client Interface. II 
reprend les concepts du support JDBC du framework afin de simplifier l'utilisation de 
cette API, d'encapsuler le code repetitif, de masquer sa complexite et de configurer la 
participation aux transactions. 

CCI donne la possibilite de parametrer la connexion grace a 1' implementation de l'inter- 
face Connecti onSpec du connecteur. Le support CCI de Spring permet la mise en oeuvre de 
cette fonctionnalite par 1' intermediate de la classe Connecti onSpecConnectionFactoryAdap- 
ter du package org.springframework. jca.cci .connection, correspondant a un proxy sur la 
fabrique de connexions cible. 

Le code suivant donne la configuration de ce mecanisme : 
(...) 

<bean id="targetConnect ion Factory" class="org.springf ramework. jca 

.support. Local Connect ion Factory Bean" > 

(...) 

</bean> 

<bean id= "my Connect ion Factory" class="org.springf ramework. jca.cci 
.connect ion. Connecti onSpecConnecti on FactoryAdapter"> 
<property name="targetConnecti on Factory" 

ref="targetConnect ion Factory "/> 
<property name= " connect ionSpec"> 
<bean 

class="com.sun.connector.ccibl ackbox.Cci Connect ionSpec"> 
<property name="username" val ue="root"/> 
<property name="password" value=""/> 
</bean> 
</property> 
</bean> 

Le support CCI de Spring propose deux approches afin d'executer des requetes, l'une 
fondee sur le template, l'autre etant une approche objet. 

La classe centrale de l'approche fondee sur le template est CciTempl ate, localisee dans le 
package org.springframework. jca.cci .core. Elle permet de travailler directement sur les 
ressources CCI qu'elle gere par le biais de methodes de rappel, aux niveaux de la 
connexion et de 1' interaction. 

Elle s'appuie pour cela sur les interfaces ConnectionCallback et InteractionCallback. La 
premiere met a disposition la connexion grace a la methode doInConnection, comme ci- 
dessous : 

public interface ConnectionCallback { 

Object doInConnectiontConnection connection, 

Connecti on Factory connect ion Factory) 
throws ResourceException, 

SQLException , Data Access Except ion; 

} 
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La seconde met a disposition l'interaction grace a la methode dolnlnteraction : 

public interface InteractionCallback { 

Object dolnlnteractiondnteraction interaction, 

Connection Factory connect ion Factory) 
throws ResourceException, 

SQLException , Da taAccess Exception ; 

} 

Le template CCI utilise ces interfaces par l'intermediaire des methodes execute de la 
maniere suivante : 

CciTemplate template = getCciTempl ate( ) ; 
template. execute(new InteractionCal 1 back( ) { 

public Object dolnlnteractiondnteraction interaction, 

Connection Factory connect ion Factory) 
throws ResourceException, 

SQLException, DataAccessException { 

IndexedRecord input = 

recordFactory .create I ndexedRecordt "input" ) ; 
input. add(new Integer(id) ) ; 
Cci InteractionSpec interactionSpec = 

new Cci InteractionSpec( ) ; 

interactionSpec. setSql ( 

"select * from todo where id=?"); 
Record output = interaction. execute( 

interactionSpec, input); 
return extractDataFromRecord(output) ; 

} 

}); 

Le template CCI offre des fonctionnalites permettant de masquer tout le code d' invoca- 
tion d'une requete par l'intermediaire de ses autres methodes execute. Ces dernieres 
s'appuient sur l'interface RecordCreator afin de definir la facon de creer une instance de la 
classe Record a partir d'un objet. Le code de cette interface est le suivant : 

public interface RecordCreator { 

Record createRecord(RecordFactory recordFactory) 

throws ResourceException, DataAccessException; 

} 

Ces methodes utilisent egalement l'interface RecordExtractor afin de recuperer les 
donnees contenues dans un Record dans un objet Java simple. Le code de cette interface 
est le suivant : 

public interface RecordExtractor { 

Object extractDatatRecord record) throws ResourceException, 

SQLException , DataAccessException ; 

} 
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Ces deux interfaces sont localisees dans le package org.springf ramework. jca.cci .core et 
peuvent etre mises en oeuvre de la maniere suivante afin d'executer une requete avec des 
classes anonymes : 

final int id = 10; 

Cci InteractionSpec interactionSpec=new Cci InteractionSpec( ) ; 
interactionSpec.setSql ("select * from todo where id=?"); 

List people=( List) getCci Tempi ate( ) . execute ( 

interactionSpec, new RecordCreator( ) { 
public Record createRecord( RecordFactory recordFactory) 

throws ResourceException, DataAccessException { 

IndexedRecord input = 

recordFactory .create Indexed Record ( "input" ) ; 
input. addtnew Integer(id)); 
return input; 

} 

}, new RecordExtractorO { 

public Object extractData( Record record) 
throws ResourceException, SQLException, DataAccessException { 

List todos=new ArrayListO; 
ResultSet rs=(ResultSet)record; 
whilet rs.nextO ) { 

Todo todo=new TodoO; 

todo.setTodoId(rs.getString( "id" ) ) ; 

todo. setDescripti on ( rs .getSt ring ( "description" ) ) ; 

(...) 

todos . add(todo) ; 

} 

return todo; 

} 

}); 

Puisque CCI definit une mefhode execute attendant le Record de retour, le template imple- 
mente un mecanisme de creation automatique de celui-ci. II s'appuie pour cela sur sa 
propriete outputRecordCreator de type RecordCreator, permettant de specifier la facon de 
le creer. Ce mecanisme est particulierement interessant pour les connecteurs ne supportant 
que cette facon de realiser des requetes. 

En parallele du template, le support CCI offre la possibility de definir les requetes CCI 
sous forme d'objets afin de beneficier de toutes les possibilites du langage objet. Cette 
approche se fonde sur la classe abstraite MappingRecordOperation du package org. spring- 
framework, jca .cci .object. Elle doit etre etendue afin d'implementer les methodes crea- 
telnputRecord et extractOutputData decrivant respectivement la fafon de creer un Record 
et d'extraire les donnees du Record renvoye. 

La classe suivante decrit 1' adaptation de l'exemple de la section precedente a 1' approche 
objet : 

public class TodosOperation extends MappingRecordOperation { 
public TodosOperation(ConnectionFactory connectionFactory, 



Technologies d integration Java 



Chapithe 13 



InteractionSpec interactionSpec) { 

super (connect ion Factory , interact ionSpec) ; 

} 



protected Record createInputRecord( 

RecordFactory recordFactory . Object inputObject) 

throws ResourceException, DataAccessException { 

Integer id=( Integer) inputObject; 
IndexedRecord input = 

recordFactory .create I ndexedRecord( "input" ) ; 
input. add(id) ; 
return input; 



protected Object extractOutputData( 

Record outputRecord) throws ResourceException, 

SQLException, DataAccessException { 

List todos=new ArrayListO; 
Resul tSet rs=( Resul tSet) outputRecord; 
while( rs.nextO ) { 

Todo todo=new TodoO; 
todo.setTodoId(rs.getString("id")); 
todo. setDescripti on (rs.getString( "description")) ; 
(...) 

todos . add(todo) ; 

} 

return todos; 

} 

} 

Cette classe peut etre utilisee de la maniere suivante dans un composant d'acces aux 
donnees : 

Cci InteractionSpec interact!' onSpec=new Cci InteractionSpect ) ; 
interactionSpec. setSql ("select * from todo where id=?"); 

TodosOperation operation=new TodosOperation( 

getConnecti on Facto ry( ) , interactionSpec) ; 
operation. execute (new Integer (10) ) ; 

Notons la presence de la classe MappingCommAreaOperation, qui etend la classe MappingRe- 
cordOperati on afin de travailler directement sur des tableaux d'octets. Cette classe facilite 
l'utilisation des connecteurs tels que celui utilise dans le cas de CICS ECI et qui echange 
des donnees en se fondant sur une COMMAREA (correspondant a un tableau d'octets). 
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Communications entrantes 

La version 2.0 de Spring ne fournit pas, au moment de l'ecriture de cet ouvrage, de 
support afin de configurer les communications entrantes, mais cette problematique 
devrait etre adressee avec la version 2.1. 

Par contre, le projet Jencks offre la possibilite de les mettre en oeuvre en utilisant les 
fonctionnalites de Spring. 

Configuration du conteneur 

Tout d'abord, il convient de configurer le connecteur ainsi que l'entite de gestion du 
connecteur pour les connexions entrantes, entite designee par Jencks sous le terme conteneur 
JCA et implemented par la classe JCAContainer du package org. jencks. 

Ce conteneur se charge de demarrer le connecteur avec le contexte specifie et de l'arreter 
en se fondant sur le cycle de vie des Beans configures dans Spring. Le connecteur est 
configure en tant que Bean par 1' intermediate de son implementation de l'interface 
ResourceAdapter. La configuration de ce conteneur se realise de la maniere suivante avec 
le connecteur du fournisseur JMS ActiveMQ : 

<bean id="jencks" class="org. jencks. JCAContainer"> 
<!-- Configuration du contexte de demarrage --> 
<property name="bootstrapContext"> 
<bean 

cl ass="org. jencks. factory .Boot st rapContext Factory Bean" > 
<property name="threadPoolSize" value="25"/> 
</bean> 
</property> 

<!-- Configuration du ResourceAdapter du connecteur --> 
<property name="resourceAdapter"> 

<bean id="acti veMQResourceAdapter" 

cl ass="org.acti vemq. ra .Acti veMQResourceAdapter "> 
<property name="serverUrl " 

val ue="tcp: //l ocal host: 61616 "/> 

</bean> 
</property> 
</bean> 

Definition de points d'activation 

Une fois le conteneur mis en oeuvre, les differents points d'acces au connecteur peuvent 
etre specifies afin que le systeme d'information d'entreprise puisse les utiliser et remonter 
des informations. 

L' implementation de l'interface Acti vati onSpec relative au connecteur JCA doit etre utili- 
see a cet effet. Puisque nous avons choisi d'utiliser le fournisseur JMS ActiveMQ, 
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1' implementation correspond a la classe ActiveMQActivationSpec. Cette classe permet de 
specifier le domaine du point d' entree ainsi que son nom. 

Dans l'exemple ci-dessous, nous creons un point d'acces sur le connecteur de type 
javax. jms .Queue, dont le nom est tudu. queue : 

<bean id="inboundConnector" class="org. jencks. JCAConnector"> 
<property name="jcaContainer" ref=" jencks"/> 

<property name="acti vationSpec"> 

<bean class="org.activemq. ra.Acti veMQActi vationSpec"> 
<property name="destination" value="tudu.queue"/> 
<property name="destinationType" 

val ue=" javax. jms. Queue "/> 

</bean> 
</property> 

<property name="ref" value="asynchTuduJmsListener"/> 
</bean> 

<bean id="asynchTudu Jms Listener" 

cl ass=" tudu. jms .AsynchTudu Jms Listener "/> 

Cette configuration utilise un observateur JMS classique afin de recevoir les messages 
JMS dont l'identifiant est asynchrTuduJmsListener. 

En resume 

Le support JCA de Spring reduit la complexite liee a 1' utilisation de l'API Common 
Client Interface pour les communications sortantes, tout en permettant d'utiliser les 
connecteurs dans et hors des serveurs d' applications. 

Le framework Jencks offre un complement permettant de configurer les connexions entran- 
tes pour des connecteurs. Par ce biais, il est notamment possible de mettre en oeuvre des 
observateurs JMS afin d'utiliser les mecanismes asynchrones de communication. 

Tudu Lists : utilisation de JMS et JCA 

La mise en ceuvre de JMS et JCA dans l'application Tudu Lists permet d'implementer 
l'envoi de messages JMS lors de la realisation de taches par le biais d'une file JMS nominee 
tudu . queue. Des applications autonomes sont a l'ecoute de ces messages afin d'afficher leurs 
contenus. Ces fonctionnalites sont disponibles dans le projet Tudu-SpringMVC. 

Tudu Lists propose deux approches afin d'implementer cette fonctionnalite. La premiere 
s'appuie sur JMS et la seconde sur JCA. La figure 13.6 illustre les mecanismes mis en 
oeuvre. 

Toutes les classes relatives a la mise en ceuvre de ces technologies sont localisees dans le 
fichier applicationContext-jms.xml du repertoire WEB-INF. 
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Figure 13.6 

Implementation des mecanismes JMS et JCA dans Tudu Lists 



L' application necessite la mise en oeuvre d'un fournisseur JMS. Nous avons choisi 
d'utiliser ActiveMQ a cet effet. Ann de garantir le bon fonctionnement de l'applica- 
tion, il est necessaire de demarrer ce fournisseur JMS de maniere autonome par l'inter- 
mediaire du script build. xml, localise a la racine du projet. Ce script peut etre execute 
dans Eclipse en le selectionnant et en choisissant le menu contextuel Run As/ Ant 
Build. 

Configuration de I'intercepteur 

Ann de ne pas impacter le code de 1' application existante, nous creons un intercepteur en 
POA afin d'ajouter le mecanisme d'envoi de messages JMS. Nous detaillons l'imple- 
mentation de ce composant a la section relative a l'envoi des messages JMS. 

Nous appliquons cette entite sur le composant de la couche service metier TodoManager. 
Le tissage de I'intercepteur se realise de la maniere suivante dans le fichier application- 
Contextxml du repertoire WEB-INF : 

<bean id="todosManager" cl ass=" org. spring-framework, transact ion 

.interceptor .Transact!' on Proxy Factory Bean "> 

(...) 

<property name="target" ref="todosManagerTarget" /> 
<property name="preInterceptors"> 
<list> 

<ref bean="jmsInterceptor"/> 
</list> 
</property> 
(...) 

</bean> 

Dans la mesure ou nous utilisons le fournisseur JMS ActiveMQ arm d'echanger des 
messages JMS, il est necessaire de configurer la fabrique de connexions relative a cet 
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outil ainsi que le template JMS de Spring et l'intercepteur. Cette configuration est localisee 
dans le fichier applicationContext-jms.xml, comme ci-dessous : 

<bean id="connectionFactory" 

cl ass=" org. act ivemq. Act i veMQConnecti on Factory "> 
<property name="brokerURL" value="tcp://localhost:61616"/> 
</bean> 



<bean id="templ ate" 

class="org. spring-framework, jms.core. JmsTempl ate"> 
<property name=" connect ion Factory" ref=" connect ion Factory "/> 
<property name="defaul tDestinationName" val ue="tudu. queue "/> 

</bean> 



Envoi des messages 

L'envoi des messages est declenche par l'intercepteur Jmslnterceptor, localise dans le 
package tudu. jms. 

II permet de creer un objet de type TuduMessage, suite a l'execution d'un traitement pour 
un todo. Cet objet contient les informations relatives au todo impacte ainsi que 1' opera- 
tion realisee. II est cree de la maniere suivante par le biais de la methode createTudu- 
Message de l'intercepteur : 

private TuduMessage createTuduMessage( 

Methodlnvocation invocation) { 
String methodName = invocation. getMethod( ) .getName( ) ; 
Object[] args = invocation. getArguments( ) ; 
if( args[0] instanceof String ) { 
String todold = (String)args[0] ; 



TuduMessage message = new TuduMessaget); 
message. setOperationType (methodName) ; 
message. setTodoId(todoId) ; 
return message; 
} else { 

Todo todo = (Todo)args[0] ; 



TuduMessage message = new TuduMessaget); 
message. setOperationType (methodName) ; 
message. setTodoId( todo. getTodoId( ) ) ; 
message.setTodoCompl eted(todo.isCompleted( ) ) ; 
message. setTodoCreationDate( todo. getCreationDate( )) ; 
message. setTodoDescripti on ( todo. getDescripti on ( ) ) ; 
message. setTodoPriority( todo. getPriority( ) ) ; 
return message; 

} 

} 
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Notons que la methode precedente gere les methodes utilisant des parametres de types 
String (cas de la methode findTodo de l'interface TodosManager) et Todo (cas des methodes 
updateTodo de cette meme interface). 

Une fois cet objet cree, le support JMS de Spring est utilise afin de l'encapsuler dans un 
message JMS de type ObjectMessage et de l'envoyer. Ces traitements sont realises de la 
facon suivante par 1' intermediate de la methode sendMessage de l'intercepteur : 

private void sendMessage(final TuduMessage message) { 
template. sendtnew MessageCreator( ) { 
public Message createMessage( 

Session session) throws JMSException { 
ObjectMessage ObjectMessage = 

session.createObjectMessage( ) ; 



L'intercepteur decrit dans cette section est configure dans le fichier applicationContext- 
jms.xml de la maniere suivante : 

(...) 

<bean id="jmsInterceptor" class="tudu. jms . JmsInterceptor"> 

<property name="templ ate" ref="templ ate"/> 
</bean> 

Reception des messages 

Tudu Lists offre deux possibilites pour recevoir les messages JMS precedents, toutes 
deux de maniere asynchrone. 

La premiere s'appuie sur le support JMS de Spring et la seconde sur le conteneur JCA de 
Jencks. 

La configuration de la premiere se realise de la maniere suivante dans le fichier application - 
Context-listenerjms.xml : 




ObjectMessage. setObject (message) ; 
return ObjectMessage; 



}); 



<bean id="connectionFactory" 

cl ass= "org. act i vemq.ActiveMQConnect ion Factory "> 
<property name="brokerURL" value="tcp://localhost:61616"/> 
</bean> 



<bean id="jmsContainer" class="org.springframework.jms 

. 1 istener.Simpl eMessageListenerContainer"> 
<property name="connectionFactory" ref="connectionFactory"/> 
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<property name="destinationName" value="tudu.queue"/> 
<property name="messageListener" ref="asynchTuduJmsLi stener"/> 
</bean> 

<bean id="asynchTudu Jms Listener" 

cl ass="tudu. jms .AsynchTuduJms Listener "/> 

La configuration de la seconde se realise de la maniere suivante dans le fichier application- 
Context- jencks.xml : 

<bean id="jencks" class="org. jencks. JCAContainer"> 
<property name="bootstrapContext"> 
<bean 

cl ass="org. jencks .factory .Boots trapContext Factory Bean" > 
<property name="threadPoolSize" value="25" /> 
</bean> 
</property> 

<property name="resourceAdapter"> 

<bean id="acti veMQResourceAdapter" 

cl ass="org.acti vemq. ra .Acti veMQResourceAdapter "> 
<property name="serverUrl " 

val ue="tcp://l oca 1 host : 6161 6" /> 

</bean> 
</property> 
</bean> 

<bean id="inboundConnector" class="org. jencks. JCAConnector"> 
<property name="jcaContainer" ref="jencks" /> 

<property name=" acti vat ionSpec"> 

<bean class="org.activemq. r a. Acti veMQActi vationSpec"> 
<property name="destination" value="tudu.queue"/> 
<property name="destinationType" 

val ue="javax. jms. Queue "/> 

</bean> 
</property> 

<property name="ref" value="asynchTuduJmsListener"/> 
</bean> 

<bean id="asynchTudu Jms Listener" 

cl ass="tudu. jms .AsynchTuduJms Listener "/> 

L'une et l'autre approches peuvent etre utilisees directement dans une application Java 
autonome par l'intermediaire d'une classe du type suivant : 

public class AsynchTuduListenerMain { 
(...) 

public static void main(String[] args) { 

ClassPathXmlApplicationContext context=null ; 
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try { 

context=new CI assPathXml Appl icationContextt 

getAppl i cationContextFi let);); 
Thread. sleep(60000) ; 
} catch(Exception ex) { 

(...) 
} finally { 

if( context!=null ) { 
context. closet ) ; 

} 

} 

System. exit(O) ; 

} 

} 

La methode getAppl i cati onContextFi 1 e renvoie le nom du fichier XML de Spring suivant 
l'approche souhaitee : applicationContext-listenerJms.xml pour 1' utilisation du 
support JMS de Spring et applicationContext-jencks.xml pour l'utilisation de Jencks. 

Ces deux fichiers sont localises dans le repertoire JavaSource du projet Tudu-SpringMVC. 



Conclusion 

J2EE propose differentes specifications pour integrer les applications Java/J2EE dans les 
systemes d'information d'entreprise. Les technologies correspondantes sont JMS, afin 
d'interagir avec des middlewares orientes messages, et JCA, afin d'acceder a des applications 
d'entreprise utilisant diverses technologies. 

Ces specifications ne sont pas d'une utilisation facile dans les applications Java/J2EE, car 
elles impliquent le recours conjoint a des mecanismes synchrones et asynchrones, tout en 
gerant des transactions plus complexes sur plusieurs ressources. 

Spring offre un support pour ces deux technologies permettant de les configurer simple- 
ment en masquant la complexite de leur utilisation dans les applications. Leur mise en 
ceuvre avec la POA permet de faire interagir des composants existants dans des systemes 
d'information d'entreprise sans impacter le code de ces composants et simplement au 
moment de 1' assemblage de 1' application. 
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Apres les technologies d'integration Java, abordees au chapitre precedent, nous allons 
detailler de quelle maniere le XML permet d'integrer des systemes heterogenes, distants 
et faiblement couples. 

Presentee a ses debuts comme une solution miracle pour 1' integration des donnees, le 
XML se revele une technologie d'usage complexe, souvent peu performante, mais 
surtout surcharged d'une plethore de normes obscures. 

Nous verrons dans un premier temps de quelle maniere faire du XML simplement et efh- 
cacement, en utilisant des bibliotheques generiques (JDOM) ou specialisees (Rome). 
Nous verrons notamment comment integrer notre application Tudu Lists a la page 
d'accueil de Google via un flux RSS. 

Linformatique d'entre prise est envahie de concepts tels que le SOA ou les services Web 
adjoints au XML. Nous allons definir ces termes, ainsi qu'en montrer les aspects utiles en 
matiere d' architecture logicielle et en detailler les principales normes, SOAP et WSDL 
en particulier. 

En fin de chapitre, nous donnerons un exemple de mise en oeuvre de service Web en 
publiant dans Tudu Lists un Bean Spring en tant que service Web a l'aide de deux 
frameworks Open Source populaires, XFire et Axis. Nous insisterons sur leurs avantages 
et inconvenients et construirons une application Swing simple permettant d'appeler ce 
service Web, arm d'illustrer son fonctionnement. 
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Le XML sur HTTP 

Bien que nous n'utilisions dans cette section aucune API Spring specifique, les exemples 
qui la parsement sont realises a l'aide de Beans Spring standards. Spring offre une archi- 
tecture permettant de gerer aisement la problematique du XML sur HTTP, sans ajout 
d'une surcouche supplemental. Nous verrons que cela n'est pas necessaire, car il ne 
s'agit pas d'un sujet si complexe. 

Envoyer du XML via un flux HTTP est une methode utilisee depuis de nombreuses 
annees afin de faire communiquer entre elles deux applications distantes. Cette solution 
est d'autant plus seduisante qu'elle est simple a mettre en oeuvre et que les grands langages 
de programmation offrent tous un excellent support de la technologie XML. 

Pour peu que nous nous mettions d' accord au prealable sur le format d'echange, il est 
done aise de faire communiquer des applications developpees dans des langages 
differents. 

Cette technique se heurte toutefois aux trois ecueils suivants : 

• La lecture de documents XML est complexe si nous utilisons les API Java standards. 
De plus, l'ecriture de documents XML est souvent mal supportee. Une API permettant 
d'ecrire du XML a done son utilite si nous voulons produire un document complexe en 
suivant une DTD. 

• Faire corresponds un ensemble d'objets avec un document XML n'est pas simple. II 
est possible de parler de mappage objet/XML, a la maniere du mappage objet/rela- 
tionnel. 

• Le XML etant un metalangage, il n'existe pas de norme definie pour specifier un 
format d'echange. Cette souplesse exige en contrepartie un temps important de speci- 
fication. Comment, par exemple, specifier un champ de date ? 

Ces difficultes se retrouvent dans la creation de services Web, que nous detaillons plus 
loin dans ce chapitre. 

Nous allons pour l'instant nous armer d'outils efficaces, qui nous permettront de resou- 
dre le plus simplement possible la problematique de 1' envoi de donnees XML via HTTP. 



Lecture et ecriture avec JDOM 

II existe des API standards pour lire le XML, nommement DOM (Document Object 
Model) et SAX (Simple API for XML), mais la premiere est reputee trop lente, et la 
seconde trop complexe. Nous estimons pour notre part que la realite confrrme largement 
ce jugement et que ces API ne sont pas utilisables par quiconque souhaite delivrer son 
projet a temps. Par ailleurs, elles ne reglent pas le probleme de l'ecriture du XML, qui est 
pour l'instant notre premiere tache : avant de lire un flux XML, il faut pouvoir l'ecrire. 

Nous rencontrons souvent en entreprise des developpeurs qui, suite a ces difficultes, 
fondent leurs applications sur des concatenations et des recherches de chaines de caracteres. 
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II s'agit la d'une erreur majeure au vu du grand nombre d'outils deja disponibles sur le 
marc he, qui permettent de lire et d'ecrire du XML de maniere simple et conviviale. 

Dans Tudu Lists, nous utilisons une bibliotheque Open Source tres populaire, nommee 
JDOM, disponible a l'adresse http://www.jdom.org. Sans etre particulierement performante, 
cette bibliotheque permet de lire et d'ecrire sans difficulte du XML et repond a tous les 
besoins d'integration simple (pour des besoins plus particuliers, voir la section « Les services 
Web », plus loin dans ce chapitre). 

Dans Tudu Lists, nous avons besoin d'une solution de backup et de recuperation des 
donnees. Le XML nous paraissant un systeme de stockage pertinent pour cela, nous 
creons deux methodes specifiques dans le Bean todoListsManager : backupTodoListt ), 
pour ecrire une liste au format XML, et restoreTodoLi st( ), pour le lire. 

Voici une version simplifiee de la premiere methode : 

public Document backupTodoListdodoList todoList) { 
Document doc = new DocumentO; 
Element todoListElement = new ElementCtodolist"); 
todoLi st El ement . addCon tent ( new El ement( "ti tl e" ) 
. addContent(todoLi st .get Name ( ) ) ) ; 

Element todosEl ement = new El ement( "todos" ) ; 
for (Todo todo : todoList. getTodost ) ) { 
Element todoEl ement = new El ement( "todo" ) ; 
todoElement.setAttribute( "id" , todo.getTodoIdt ) ) ; 
todo El ement. addContentt new El ement ("description") 

.addContent(todo.getDescription( ) ) ) ; 
todo El ement. addContentt new El ement ("priority") 

.addContentt Integer . toSt ring (todo. get Prior i ty ( ) ) ) ) ; 
todo El ement .addContentt new El ement ( "completed" ) 

. addConten t ( Bool ean . toSt ring (todo. i sCompl eted( ) ) ) ) ; 

todos El ement .addContent(todoEl ement) ; 

} 

todoList El ement .addContentt todos El ement) ; 

doc. addContentt todo Li stEl ement) ; 
return doc; 

} 

Ce code cree un document XML de la forme suivante : 

<todol i st> 
<title>Liste de taches</title> 
<todos> 

<todo id="4028944508eb569d0108ef0c72c30023"> 

<description>Premiere tache a faire</description> 

<priority>100</priori ty> 

<compl eted>f al se</compl eted> 
</todo> 

<todo id="4028944508eb569d0108ef0c3aac0022"> 
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<description>Deuxieme tache a faire</description> 
<priority>50</priori ty> 
<compl eted>f al se</compl eted> 
</todo> 
</todos> 
</todolist> 

Un Element est un nceud XML que nous ajoutons a l'aide de la methode addContentt ). 
L'ajout d'un attribut a un noeud existant s'effectue grace a la methode setAttributet ). 
L'API JDOM est done en pratique extremement simple. 

Pour la lecture, Tudu Lists propose des fonctionnalites assez completes de creation, 
remplacement et fusion de listes. Voici, une nouvelle fois en version simplifiee, le code 
lisant le flux XML : 

import org. jdom. Document; 

import org. jdom. Element; 

import org. jdom. input. SAXBuilder; 

( ... ) 

SAXBuilder saxBuilder = new SAXBui lder( ) ; 
Document doc = saxBuilder. build(inputStream) ; 
Element rootElement = doc.getRootEl ementt ) ; 

String title = rootElement. getChildTextCtitle") ; 

TodoList todoList = new TodoListO; 

todoLi st. setName( title) ; 

todoLi stDAO.saveTodoLi st( todoList) ; 

Element todosElement = rootElement .getChi ld( "todos" ) ; 
List todos = todosElement. getChildrenO; 
for (Object todoObject : todos) { 

Element todoElement = (Element) todoObject; 

Todo todo = new TodoO; 

todo.setDesc riptionttodo Element. getChi 1 dText( " description")); 
todo. setPriority( Integer. val ueOf ( 

todoElement .getChi ldText( "priority" ) ) ) ; 
todo.setCompl etedtBool ean .parseBooleant 

todoElement .getChi ldText( "compl eted" ) ) ) ; 

} 

todo.setTodoList(todoList) ; 
todoLi st. getTodost ) . add (todo) ; 
todoDAO.saveTodo(todo) ; 

} 

De meme que pour l'ecriture, 1' API utilisee est tres claire. Nous commencons par construire 
un Document JDOM a partir d'un objet de type java.io.InputStream. Une fois cet objet 
cree, nous pouvons lire le nceud racine grace a la methode getRootEl ement, lire les enfants 
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d'un noeud avec la methode getChildren( ) ou lire le contenu d'un noeud avec la methode 
getChildText( ). Voila qui est nettement plus pratique que les API DOM et SAX. 

Les deux methodes que nous venons de mettre en oeuvre autorisent l'ecriture et la lecture 
d'un flux XML. Elles sont contenues dans la couche metier de l'application. II est possi- 
ble, dans les couches superieures de l'application, de les transporter de differentes 
manieres. Nous ne sommes en aucun cas lies au protocole HTTP. Par exemple, nous 
venons de voir que la methode de lecture avait comme point de depart un objet de type 
java. io. InputStream, ce qui est tres generique. Le HTTP etant cependant une methode de 
transfert de donnees particulierement simple d' utilisation, c'est elle que nous retenons 
pour les phases d'envoi et de reception des documents XML traites. 

Pour l'envoi du document XML, nous utilisons une Action Struts, tudu.web.BackupTodo- 
ListAction, dans laquelle Spring injecte le Bean todoListsManager. Cette Action renvoie 
vers une servlet faisant office de vue, tudu.web.servlet.BackupServlet, qui envoie elle- 
meme le XML grace a XMLOutputter, un objet JDOM specifique qui formate le XML : 

XMLOutputter outputter = 
new XMLOutputter ( Format .get Pretty Formate ) ) ; 

Writer writer = response. getWritert ) ; 
outputter. outputtdoc, writer); 
writer. close( ) ; 

Pour la reception du document XML, nous utilisons la fonctionnalite d' upload de fichiers 
de Struts et transformons ce fichier en objet java. io. InputStream. 

En resume, nous constatons que l'utilisation de JDOM, en conjugaison avec une couche 
de presentation classique fondee sur des Actions Struts et des servlets, permet de realiser 
simplement et rapidement une interface d'echange XML sur HTTP. De plus, le code 
resultant est concis et rapidement comprehensible. 



Publication d'un flux RSS 

Le RSS (Really Simple Syndication) est un format largement repandu permettant l'agre- 
gation de contenu simple, essentiellement des informations telles que des nouvelles ou 
des actualites. Ce format se retrouve notamment sur les blogs ou les wikis. 

Sous l'ombrelle RSS se cache en realite une multitude de formats, si bien que l'utilisa- 
tion directe de JDOM peut se reveler complexe. Heureusement, la bibliotheque Open 
Source Rome nous aide dans cette tache. Elle est disponible a l'adresse http://wiki.java.net/ 
bin/view/Javawsxml/Rome. 

Rome illustre a merveille la pertinence de l'approche que nous venons de presenter 
puisqu'elle est elle-meme fondee sur JDOM. 

Pour Tudu Lists, l'ajout d'un flux RSS presente l'interet tout particulier de permettre aux 
utilisateurs d'agreger leurs listes de taches et, dans le cadre de listes partagees, d'etre 
rapidement informes des actions des autres utilisateurs. 
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La methode de publication du flux RSS est similaire a celle que nous avons deja vue pour 
la publication d'un flux XML classique. Nous utilisons Spring pour injecter le Bean 
todoListsManager dans l'Action Struts tudu.web.ShowRssFeedAction et renvoyons vers une 
servlet jouant le role de vue. 

Cette servlet utilise l'API de Rome pour generer un flux RSS au sein de sa methode 
doGetO (precisons que les packages utilises commencent par com. sun car il s'agit a 
l'origine d'une API developpee par des ingenieurs travaillant chez Sun) : 

import com.sun.syndication.feed.synd.SyndContent; 

import com. sun. syndication. feed. synd.SyndContentlmpl ; 

import com.sun.syndication.feed.synd.SyndEntry ; 

import com. sun. syndication. feed. synd.SyndEntrylmpl ; 

import com. sun . syndi cati on . feed . synd . SyndFeed ; 

import com. sun. syndi cati on. feed. synd. SyndFeedlmpl ; 

import com. sun . syndi cati on . i o . FeedExcepti on ; 

import com. sun. syndi cati on. io.SyndFeedOutput; 

SyndFeed feed = new SyndFeedlmpl () ; 
feed. set FeedType( "rss_2.0" ) ; 
feed.setTitl e( todo List .get Name ( ) ) ; 
feed.setLinkd ink) ; 

feed.setDescriptiont "Tudu Lists | " + todoList.getNameO); 
Li st<SyndEntry> entries = new ArrayLi st<SyndEntry>( ) ; 
for (Todo todo : todos) { 

SyndEntry entry = new SyndEntrylmpl ( ) ; 

entry. setLinkdink + "?listld=" 
+ todoList.getListId( ) + "#todoId" + todo.getTodoId( )) ; 

entry. setTitle(todo.getDescription( )) ; 

entry. setPubl ishedDate(todo.getCreationDate( ) ) ; 

SyndContent description = new SyndContentlmpl ( ) ; 

descripti on. setTypet "text/plain") ; 

description.setValue(todo.getDescription( ) ) ; 

entry .set Descripti on (descripti on) ; 

entries. add(entry) ; 

} 

feed.setEntries(entries) ; 

response. setContentType( "application/xml ; charset=UTF-8" ) ; 

SyndFeedOutput output = new SyndFeedOutput( ) ; 
try { 

output. output (feed, response. getWritert ) ) ; 
} catch (FeedException fe) { 
String msg = "The RSS feed could not be generated."; 
log.error("Error while generating the RSS feed : " + 

fe.getMessaget ) ) ; 
response. sendError(HttpServl et Response. 

SC_INTERNAL_SERVER_ERROR,msg) ; 

} 
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Ce code montre bien que Rome propose de renseigner chaque element du flux RSS en 
tant qu'objet Entry, lequel possede les attributs classiques que nous retrouvons en RSS : 
un lien, un titre, la date de publication et une description. 

Ce travail permet d' integrer des listes de todos dans tout logiciel proposant le format 
RSS, ce qui est le cas de la page d'accueil personnalisee de Google. La figure 14.1 illus- 
tre une copie d'ecran de Google affichant la liste « Exemple RSS », laquelle comporte 
meme une tache ecrite en chinois, afin de bien montrer que l'ensemble est parfaitement 
integre. 

Figure 14.1 

Integration dun flux We b Images Groups News Frooqle Local more » 

RSS de Tudu Lists 
dans la page 

d'accueil de Google Google Search | I'm Feeling Lucky | 

New! View this page anytime on your mobile phone . 



edit [x] Exemple RSS edit [x] 

Une tache a realiser 

Une autre tache 



Gmail edit [x] 



En resume 

Nous avons vu avec quelle facilite nous pouvions utiliser le XML pour integrer une 
application Java a d'autres systemes. Que ce soit avec JDOM ou Rome, le code ecrit reste 
concis et lisible. Ajoutons que le decoupage en couches de l'application et l'utilisation de 
Spring nous ont permis d' avoir des interfaces metier claires, ce qui facilite grandement le 
travail. 

Cependant, nous n'avons pour l'instant traite que des exemples simples, avec des interfa- 
ces bien definies, comme le RSS. Nous allons voir a la section suivante comment integrer 
des systemes plus complexes, grace a l'utilisation des services Web. 

Les services Web 
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Les services Web, ou Web Services, sont un ensemble de specifications, particulierement 
complexes, visant a faire communiquer des applications distantes via un format XML 
standardise. 
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La Web Services Interoperability Organization propose une specification complete, 
nominee Basic Profile, qui garantit qu'un service Web peut etre utilise sans probleme, 
quel que soit le langage de programmation utilise. Cette specification, ainsi qu'un outil 
permettant de verifier la conformite d'un service Web, est disponible sur le site Web de 
1' organisation, a l'adresse http://www.ws-i.org/. 

Cette technique d'integration de systemes est souvent couplee au concept de SOA 
(Service Oriented Architecture). Le style d' architecture SOA prone la creation d'applica- 
tions developpees en couches, avec une couche metier mise a la disposition d'autres 
applications. En ce sens, une application Spring est une candidate toute designee pour 
faire du SOA, puisqu'il s'agit d'offrir un acces a la couche metier (les Beans todosManager 
et todoListsManager dans notre exemple). 

Notons bien que les services Web ne sont qu'un moyen parmi d'autres de publier des 
services metier distants. Si nos applications sont toutes developpees en Java, par exem- 
ple, 1' utilisation de RMI est a la fois plus simple et plus efficace que celle des services 
Web. 

Spring offre egalement le support d'autres protocoles, comme Burlap et Hessian, qui 
sont eux aussi plus performants que les services Web classiques. 

Reste que 1' utilisation de services Web est un bon moyen de publier une couche metier de 
maniere independante du langage d'implementation, tout en suivant les grands standards 
actuels du marche. C'est ce que nous allons voir dans le reste de cette section. 



Concepts des services Web 

Les services Web s'appuient sur une trentaine de specifications, dont nous ne detaillons 
ici que les deux principales, SOAP et WSDL. Ces specifications sont toutes emises par le 
W3C (World-Wide Web Consortium) et sont par consequent des standards internationaux 
largement reconnus. 

SOAP signifiait a l'origine « Simple Object Access Protocol » (le nom complet n'est plus 
utilise). II s'agit d'un protocole permettant de decrire des objets dans un format XML, 
afin de pouvoir echanger ces objets via Internet. 

Les applications SOAP utilisent essentiellement le protocole HTTP pour effectuer ces 
echanges d'objets, mais elles peuvent egalement utiliser d'autres protocoles, comme 
SMTP ou JMS. Malgre son nom d'origine, SOAP n'est pas un standard simple d'utilisa- 
tion. II a de plus le defaut d'etre particulierement lent, la transformation d'objets en XML 
etant un mecanisme intrinsequement cofiteux en ressources. 

WSDL (Web Services Description Language) — prononcez wizzdle — decrit de quelle 
maniere il est possible d'utiliser un service Web (protocole a utiliser, methodes accessi- 
bles, objets utilises). L'obtention d'un document WSDL est essentielle pour utiliser un 
service Web, car c'est ce document qui en donne le « mode d'emploi ». II peut etre lu par 
un logiciel pour generer automatiquement un client au service Web qu'il decrit, faisant 
ainsi office de specification technique. 



Technologies d'integration XML I 

ii iii B 

Les deux specifications que nous venons de decrire sont relativement complexes. 
Heureusement, il n'est nul besoin de les apprendre pour pouvoir les utiliser. Un ensemble 
d'outils performants permettent en effet de lire et d'ecrire du SOAP et du WSDL a notre 
place. Ces outils ont le double avantage de faire gagner beaucoup de temps (il faut compter 
une heure pour lire ou ecrire un service Web simple) et de garantir le respect des specifi- 
cations. 

Les grands editeurs d'environnements de developpement Java proposent ce type d'outils 
integres dans leur IDE. C'est le cas notamment de Sun Java Studio Entreprise et d'Oracle 
JDeveloper, pour n'en citer que deux, telechargeables gratuitement. 

Ces outils presentent toutefois les inconvenients de nous Her a 1' implementation 
SOAP de l'editeur et de n'etre generalement pas Open Source. Un service Web deve- 
loppe avec les outils Sun, par exemple, ne peut etre deploye que sur le serveur d' appli- 
cations Sun Java System Application Server. De meme, les outils Oracle utilisent 
necessairement 1' implementation SOAP d'Oracle lorsqu'ils generent un client au 
service Web. 

Pour realiser des services Web de maniere independante de l'editeur, nous optons pour 
notre part pour des outils Open Source dans le cadre de 1' application Tudu Lists. Nous 
verrons qu'ils sont egalement tres efficaces pour realiser un document WSDL ou echanger 
des objets en suivant la norme SOAP. 

En resume 

Les services Web se fondent sur une multitude de normes complexes, dont nous venons 
de decrire les deux principales, SOAP et WSDL. 

L'utilisation des services Web n'est pas evidente et entraine des contraintes importantes 
en terme d'interoperabilite et de performance. 

La section suivante se penche sur la mise en oeuvre pratique d'un service Web dans le 
cadre de 1' application Tudu Lists. 

Tudu Lists : utilisation de services Web 

Dans Tudu Lists, nous voulons presenter une partie de la couche metier en SOA, de 
maniere que des outils externes puissent consulter des listes de todos ainsi que les taches 
afferentes. 

Nous creons pour cela un Bean Spring simple, tudu. web. ws. imp! .TuduListsWebServicelmpl, 
charge de presenter les deux methodes suivantes : 

• getAllTodol_ists( ), qui retournera un ensemble de Value Objects representant des listes 
de todos. 

• getTodosByTodoList(String 1 istld), qui representera un ensemble de todos appartenant 
a une liste. 
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Ce Bean implemente l'interface tudu.web.ws.TuduListsWebService, dont voici le code : 
package tudu.web.ws; 

import tudu.web.ws. bean. WsTodo; 
import tudu.web.ws. bean. WsTodoLi st; 

public interface TuduListsWebService { 

WsTodoList[] getAl lTodoLists( ) ; 

WsTodo[] getTodosByTodol_ist(String listld); 

} 

Pour ces deux mefhodes, nous creons des Value Objects specifiques, WsTodo et WsTodo- 
Li st, car nous voulons eviter de presenter notre modele de donnees a travers un 
service Web. Une autre raison a ce choix est qu'il aurait ete difficile de modeliser un 
objet TodoList classique dans un service Web, car il possede une dependance cyclique 
avec l'objet User. 

Nous pouvons voir ainsi une premiere difference entre les services Web et une technolo- 
gie de type RMI, puisqu'il s'agit de mapper des objets Java en XML. Or cela n'est pas 
toujours evident, puisque les langages XML sont par nature hierarchiques et ne permet- 
tent done pas facilement de representer tous les types de relations pouvant lier les objets 
entre eux. 

La creation de ces objets specifiques nous evite par ailleurs de devoir publier des champs 
de type j a v a . u t i 1 . D a t e dans le service Web. Ces champs sont effet problematiques , car ils 
peuvent ne pas etre renseignes dans 1' application. L implementation SOAP fournie par 
Microsoft avec .Net ne supporte pas les champs de type Date ayant une valeur nulle, par 
exemple. 

Ce type d'incompatibilite complexifie considerablement 1' utilisation des services Web, 
engendrant une deuxieme difference de taille par rapport a la technologie RMI : des 
objets de base, comme java.util .Date, ou les structures de donnees du package 
java.util, comme les collections, ne sont que tres mal supportes par les services Web. 
C'est egalement pour cette raison que le service Web que nous sommes en train de creer 
renvoie des tableaux d'objets et non une collection d'objets. 

En resume, nous avons vu que le mappage XML/objet n'etait pas evident et que l'utilisa- 
tion d'un service Web etait tres differente d'une technologie d'acces distant, comme le 
RMI. Le plus simple est done de n'utiliser que des JavaBeans classiques et des tableaux 
d'objets. 

Nous allons maintenant publier ce Bean a l'aide de deux frameworks Open Source popu- 
lates, XFire et Axis. 
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Publication d'un Bean avec XFire et Spring 

XFire est un projet Open Source de la communaute Codehaus, disponible a l'adresse http:/ 
/xfire. codehaus. org/. 

II represente une implementation SOAP aussi performante que simple d' utilisation, qui 
propose de surcroit une bonne integration a Spring. Son seul veritable defaut est sa 
jeunesse. En l'utilisant, nous prenons done un risque plus important qu'avec des 
frameworks plus anciens, tels que Axis, que nous detaillons par la suite. 

XFire utilise la reflexion pour generer a la volee un service Web. II ne necessite aucun 
outil specifique pour cette generation, a la difference de la plupart des solutions concur- 
rentes (nous en aurons un exemple avec Axis a la section suivante). 

Nous commencons par ajouter notre Bean dans le fichier WEB-INF/application- 
Contextxml : 

<bean id="tudul_istsWebService" 

class="tudu.web.ws.impl .TuduListsWebServicelmpl "> 

<property name="todoListsManager' , > 
<ref bean="todol_istsManager" /> 
</property> 

<property name="userManager"> 
<ref bean="userManager" /> 
</property> 
</bean> 

Nous definissons ensuite un contexte Spring specifique pour XFire. Nous ajoutons pour 
cela la configuration de XFire a celle de Spring et configurons un DispatcherServlet 
specifique dans le fichier WEB-INF/web.xml : 

( ... ) 

<context-param> 
<param-name>contextConf igl_ocation</param-name> 
<param-val ue>/WEB-INF/appl icationContext*.xml ; 

classpath:org/codehaus/xfire/spring/xfire.xml 

</param-val ue> 
</context-param> 
( ... ) 
<servlet> 

<servlet-name>xf i re</servl et-name> 

<servlet-class> 
org. spring-framework, web. servlet. DispatcherServlet 

</servl et-cl ass> 
</servlet> 
( ... ) 

<servlet-mapping> 

<servl et-name>xf i re</servl et-name> 

<url -pattern>/ws/xf i re/*</url -pattern> 
</servlet-mapping> 
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Cette configuration associe les URL commencant par /ws/xfire a une servlet Spring, 
laquelle redirige ensuite les requetes envoyees a XFire. La configuration que nous avons 
chargee depuis le classpath est fournie dans le JAR de XFire afin de configurer un 
contexte Spring specifique pour les Beans de XFire. Ce fichier de configuration ressemble 
a celui de Struts, que nous avons presente au chapitre 6. 

Ce contexte est configure via un fichier nomme xfire-servlet.xml, qui se trouve dans le 
repertoire WEB-INF : 

<beans> 

<bean name="/TuduListsWebService" parent="xf i reServiceTempl ate"> 
<property name="servi ceBean"> 

<ref bean="tudul_istsWebService" /> 
</property> 

<property name=" service Interfaced 

<val ue>tudu.web.ws .Tudul_istsWebService</val ue> 
</property> 
</bean> 

<bean id="xf i reServi ceTempl ate" 

class=" org. codehaus.xf ire. spring. remoting.XFi reExporter" 
abstract="true"> 

<property name="servi ceFactory" ref="xfire.serviceFactory" /> 
<property name="xfire" ref="xfire" /> 
<property name="style" val ue="document" /> 
<property name="use" value="literal " /> 
</bean> 
</beans> 

Dans cet exemple, nous utilisons l'heritage de Beans afin de simplifier la creation de 
nouveaux Beans sur le meme modele. 

Le Bean parent, xf i reServiceTempl ate, permet de configurer le fonctionnement de XFire. 

Les Beans enfants servent a exporter des Beans Spring sous forme de service Web. Nous 
devons pour cela referencer un service et 1' interface qu'il implemente, de maniere que 
XFire puisse utiliser la reflexion sur cette interface. 

II n'y a rien d' autre a realiser pour publier un Bean Spring sous forme de service Web. 

II suffit de faire pointer un navigate ur Internet sur l'URL suivante pour recuperer le 
fichier WSDL correspondant au service Web publie : 

http://127. 0. 0. 1 :8080/Tudu/ws/xfire/TuduLists WebService ?wsdl 

Le service Web est quant a lui disponible a l'adresse : 

http://127. 0. 0. 1 :8080/Tudu/ws/xfire/TuduLists WebService 

Notons que les URL sont sensibles a la casse, d'oii l'importance de respecter les majuscules, 
notamment pour la racine du contexte (ici Tudu). 

Pour un utilisateur de Spring, XFire permet done de realiser extremement facilement des 
services Web. 
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Pour observer en detail les performances de ce service Web, nous pouvons utiliser 
JAMon, que nous avons deja presente au chapitre 9, consacre a la technologie AJAX. Ces 
tests fournissent des temps de reponse excellents, inferieurs a 30 millisecondes. 

En conclusion, XFire represente une couche SOAP simple et performante, qui n'a pour 
seul defaut que son relatif manque de maturite. 



Publication d'un Bean avec Axis et Spring 

Axis est 1' implementation SOAP de la fondation Apache. Tres largement utilise, ce 
framework mature utilise des scripts Ant arm de generer du code source, un code qui doit 
ensuite etre integre a l'application. 

Nous allons implementer avec Axis le service Web que nous venons de creer avec XFire, 
afin d'en detailler les differences d' utilisation. 

II nous faut tout d'abord telecharger Axis sur le site Web d' Apache, a l'adresse http:// 
ws. apache, org/axis/. 

Nous utilisons ensuite Ant pour generer un fichier WSDL a partir de code Java. II s'agit 
de produire par script ce que XFire genere automatiquement par reflexion. 

La generation du fichier WSDL n'est toutefois qu'une premiere etape. II faut ensuite 
generer a partir de ce fichier le service Web complet. Nous utilisons pour cela deux 
taches Ant, de la maniere suivante : 

<target name="generate-web-service"> 
<path id="axis.classpath"> 
<pathel ement path="${basedi r}/cl asses "/> 
<fileset dir="${basedir}/lib/"> 

<include name="**/*. jar" /> 
</fileset> 
</path> 

<taskdef resource^" axis -tasks .properties" 
cl as spat href =" axis .cl asspath" /> 

<axis-java2wsdl classname="tudu.web.ws.axis.AxisTLiduLists" 

output="${basedi r}/AxisTuduListsWebService.wsdl " 
namespace=" http://axis.ws.web.tudu" 

location="http://127.0.0.1:8080/Tudu/ws/axis/TuduListsWebService"> 
</axis-java2wsdl> 

<axis-wsdl 2java output="${basedi r}/generated-sources" 
testcase="fal se" 
serverside="true" 

url ="${basedi r}/AxisTuduListsWebService.wsdl " 
verbose="true"> 

</axi s-wsdl 2java> 
</target> 
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Dans ce script, nous commencons par definir un classpath comprenant les classes de 
1' application (repertoire classes) et les bibliotheques utilisees par Axis (dans le repertoire 
lib). Les JAR d'Axis ajoutent a ce classpath un fichier axis-tasks.properties, lequel 
contient deux taches Ant, la premiere pour generer un fichier WSDL depuis des classes 
Java (java2wsdl), et la seconde pour generer du code source Java depuis un fichier 
WSDL (wsdl2java). 

Pour generer le service Web, nous creons une interface qui le represente, que nous appe- 
lons tudu. web. ws. axis. AxisTuduLists. Etant donne que nous voulons que cette interface 
presente les memes methodes que le Bean tuduListsWebService, nous lui en faisons heri- 
ter : 

package tudu. web. ws. axis; 

public interface AxisTuduLists extends 
t udu. web. ws .TuduListsWebService { 

) 

Une fois cette interface compilee, nous executons le script Ant precedemment cree. Ce 
dernier genere dans un premier temps un fichier WSDL puis du code source Java fonde 
sur le framework Axis. 

Ces classes generees peuvent ensuite etre copiees dans l'arborescence du projet. Remar- 
quons que les taches Ant d'Axis remplacent alors un certain nombre de classes existan- 
tes : 

• Les JavaBeans servant a echanger des donnees, WsTodo et WsTodoLi st, sont enrichis avec 
du code specifique d'Axis. lis restent cependant des JavaBeans normaux, qui peuvent 
etre utilises en parallele par XFire. 

• L'interface Axi sTuduLi sts, que nous venons de creer, est completement modifiee. Nous 
l'avions fait heriter de TuduListsWebService de maniere que, par reflexion, Axis put 
recreer cette interface avec ces memes methodes. Les methodes generees presentent 
cependant une difference, puisqu'elles lancent des exceptions de type java.rmi .Remo- 
teException. De son cote, l'interface AxisTuduLists n'etend plus l'interface Tudu- 
ListsWebService suite au changement de signature des methodes. 

Axis a ainsi modifie un certain nombre de classes mais a aussi genere un squelette de 
service Web, qu'il nous faut maintenant implementer. II s'agit d'ecrire le code de la 
classe TuduListsWebServiceSoapBindinglmpl, qui implemente AxisTuduLists, l'interface 
que nous venons d'etudier. 

Cette implementation va publier avec Axis les methodes du Bean Spring tuduListsWeb- 
Service. C'est d'ailleurs pour cela que nous avons fonde la generation du code sur une 
interface implementant TuduListsWebService. 

Pour cela, Spring fournit la classe org. springf ramework. remoting. jaxrpc.Servl etEndpoint- 
Support, qui permet l'integration de Spring et d'Axis. En etendant cette classe, l'imple- 
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mentation que nous sommes en train d'ecrire peut acceder au contexte Spring, et done au 
Bean tuduListsWebService : 

package tudu. web. ws. axis; 

import org.springf ramework. remoting. jaxrpc.ServletEndpointSupport; 

import tudu. web. ws. TuduListsWebService; 

public class TuduListsWebServiceSoapBindinglmpl 
extends ServletEndpointSupport 
implements tudu. web. ws. axis. AxisTuduLists { 

private TuduListsWebService service; 

public final void onlnitO { 
this. service = 

(TuduListsWebService) getWebAppl icationContext( ) 
.getBeant "tudu Li stsWebService" ) ; 

} 

public tudu. web. ws. bean. WsTodoList[] getAllTodoListsO 
throws java.rmi .RemoteException { 

return service. getAl lTodoListst ) ; 



Axis impose done la generation d'un certain nombre de classes, qui doivent par la suite 
etre retravaillees en fonction du service Web que nous souhaitons proposer. Ce mode de 
fonctionnement relativement lourd exige un cout supplementaire lors de toute evolution 
du service Web, ainsi que lors d'une montee en version d'Axis. II faut, dans ces deux cas, 
generer une nouvelle fois les classes et y repercuter a nouveau les developpements prece- 
demment effectues. 

Pour cette raison, il est recommande de mettre le moins de code possible dans la classe 
implementant le service Web, comme nous venons de le faire en laissant le code metier a 
l'interieur du Bean Spring tuduLi stsWebServi ce. 

Maintenant que le service Web est developpe, il faut encore configurer le moteur d'Axis 
afin qu'il puisse publier ce service. De la meme maniere que pour XFire, il s'agit d'une 
servlet a configurer dans le fichier WEB-INF/web.xml : 

<servlet> 
<servl et-name>axi s</servl et-name> 
<servl et-cl ass> 



public tudu. web. ws. bean. WsTodo[] getTodosByTodoListtString inO) 
throws java.rmi .RemoteException { 



return service.getTodosByTodoLi st(inO) ; 
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org. apache. axis.transport.http.AxisServlet 
</servl et-cl ass> 

<1 oad-on-startup>10</load-on-startup> 
</servl et> 

( ... ) 

<servlet-mapping> 

<servl et-name>axis</servl et-name> 

<url -pattern>/ws/axis/*</url -pattern> 
</servlet-mapping> 

Cette servlet lit un fichier de configuration, qui, par defaut, se trouve a 1' emplacement 
WEB-INF/server-config.wsdd. Ce fichier de configuration est fourni par Axis, mais 
nous pouvons egalement nous appuyer sur celui de Tudu Lists. C'est en editant ce fichier 
que nous pouvons configurer Axis afin qu'il publie notre service Web. 

Lors de l'execution du script Ant, outre le code source Java genere, deux fichiers finissant 
en .wsdd sont crees. L'un de ces fichiers, deploy. wsdd, sert a deployer le service Web 
dans un serveur Axis. 

La methode la plus simple pour deployer ce service consiste a copier-coller le contenu de 
ce fichier dans le fichier server-config.wsdd : 

<?xml version="1.0" encoding="UTF-8"?> 

deployment xmlns="http://xml .apache.org/axis/wsdd/" 
xml ns :wsdd="http: //xml .apache.org/axis/wsdd/" 
xml ns : java="http: //xml .apache.org/axis/wsdd/providers/java"> 

<globalConfiguration> 

( ... ) 
</globalConfiguration> 

<handl er 

type=" java: org. apache. axis. trans port. local . Local Responder" 
name="Local Responder" /> 

( ... ) 

<service provider^" java : RPC" name="Version"> 
<parameter val ue="getVersion" name="al 1 owedMethods" /> 
<parameter val ue="org. apache. axis. Version" name="cl assName" /> 

</service> 

<servi ce name="TuduLi stsWebServi ce" 
provi der=" java : RPC" 
styl e="rpc" 
use="encoded"> 



( ... ) 
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</service> 



<transport name="http"> 

( ... ) 
</transport> 
</depl oyment> 

Une fois l'application Web configuree, le service Web Axis peut etre publie dans l'appli- 
cation. D'une maniere tres similaire a ce que nous avons vu avec XFire, nous pouvons 
acceder au WSDL de ce service Web en utilisant l'URL suivante : 

httpj/127, 0. 0. 1 :8080/Tudu/ws/axis/TuduLists WebService ?wsdl 

Le service Web est quant a lui disponible a l'adresse : 

httpj/127. 0. 0. 1 :8080/Tudu/ws/axis/TuduLists WebService 

Le service Web ainsi genere fonctionne de maniere differente de celui publie par XFire, 
et ce pour deux raisons : les parametres utilises pour creer ce service Web ne sont pas les 
memes dans les deux implementations, et ces deux moteurs n' interpreted pas toujours 
les specifications SOAP et WSDL de la meme maniere. 

Au final, l'utilisation d'Axis se revele relativement lourde. La generation de code et 
1' utilisation du fichier server-config.wsdd sont fastidieuses, tandis que les performances 
finales du service Web se revelent plus que moyennes, de l'ordre de 50 millisecondes 
dans nos tests. (Nous preferons etablir notre propre mesure de performance, en fonction 
de notre configuration materielle et logicielle, en utilisant nous-meme JAMon, comme 
nous 1' avons vu precedemment pour XFire.) Cependant, Axis etant une implementation 
particulierement repandue et stable, le service Web ainsi genere garantit une excellente 
interoperabilite, et ce quel que soit le client utilise pour y acceder. 

Enfin, Axis s'integre avec Spring de maniere assez simple, ce qui lui permet d'offrir un 
acces efficace a la couche metier de l'application. 



Utilisation d'un service Web avec Axis, sans Spring 

Afin d'illustrer le fonctionnement general d'un service Web, nous allons detailler le 
developpement d'une application Swing, nommee Tudu Lists Client, capable de se 
connecter a Tudu Lists via le service Web Axis que nous venons de developper. 

Dans cette section, nous nous concentrons uniquement sur l'utilisation d'Axis. 

Lorsqu'elle est utilisee cote client, cette bibliotheque presente de nombreux atouts, 
notamment les suivants : 

• Axis est fiable, respecte les standards et ne necessite pas de version elevee du JDK 
(version 1.3 au minimum), ce qui est important pour une application cliente. 

• Les problemes de performance d'Axis sont nettement moins importants cote client, car 
il y a moins d'appels que cote serveur. 

• L API d'Axis est particulierement simple d' utilisation. 
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Nous allons voir dans l'exemple suivant comment utiliser une application Spring en 
mode SOA. L' application Swing n'est ici qu'une couche graphique, qui utilise les methodes 
metier que publie Tudu Lists. 

L' installation de Tudu Lists Client a ete detaillee au chapitre 1. Une fois configure dans 
Eclipse, le projet Tudu Lists Client doit pouvoir etre lance en faisant un clic droit sur la classe 
tudu. cl ient. TuduCl ient et en selectionnant Run as puis Java Application dans le menu 
contextuel. 

Pour ecrire cette application, nous commencons par reprendre les classes generees par les 
taches Ant d' Axis, que nous avons deja utilisees pour creer le service Web. 

Parmi ces classes se trouve un objet permettant d'acceder au service Web, en l'occurrence 
AxisTuduListsServiceLocator, qui s'utilise de la maniere suivante : 

AxisTuduListsServiceLocator locator = 
new AxisTuduListsServiceLocatort ) ; 

client = locator. getTudul_istsWebService(url ); 
WsTodoList[] wsTodoLists = cl ient.getAl lTodoLists( ) ; 

Ce code permet d'acceder a un service Web localise a l'URL passee en parametre et d'en 
appeler directement les methodes. 

Dans l'exemple suivant, nous recuperons une liste de todos en utilisant l'objet cl ient que 
nous venons de creer : 

String listld = 
wsTodoLi sts[todol_ists .getSel ectedlndext )] .get Li stld ( ) ; 

WsTodo[] wsTodos = cl ient.getTodosByTodoListd istld) ; 
for (int i = 0; i < wsTodos. length; i++) { 
0bject[] row = {wsTodos[i].getDescription(), 
wsTodos [i ] .getPriority( ) , wsTodos [i ] . isCompleted( ) } ; 

todosTabl eModel .addRow(row) ; 

} 

L'acces aux differentes methodes du service Web se fait done simplement en Java, et 
nous pouvons ainsi utiliser a distance la couche metier de Tudu Lists pour afficher les 
listes de todos et les todos qui leur sont associes. 

La figure 14.2 illustre une copie d'ecran de l'application Tudu Lists Client, alors qu'elle 
accede a Tudu Lists. Remarquons en haut de la figure l'URL de l'application fournissant 
le service Web, ainsi que, en dessous, deux tableaux : celui du haut affiche les listes de 
todos, et celui du bas les taches associees a la liste selectionnee. 

La partie Swing de cette application est simple a developper a l'aide d'un editeur graphique, 
tel que Oracle JDeveloper ou Netbeans 5.0. 

Dans la mesure oil cette application Swing permet de presenter des informations prove - 
nant de Tudu Lists, elle peut etre consideree comme un concurrent des methodes de 



Technologies d'integration XML 




Chapitre 14 



presentation presentees precedemment dans l'ouvrage, qu'elles soient fondees sur Struts, 
Spring MVCouAJAX. 



Connect to server 



1 - Developpement 

3 - Bugs 

4 - Documentation 

2 - Test 



Une tache importante 500 false 
Une tache a realiser 100 true 
S2S ra Hs:^: o false 



Utilisation d'un service Web avec Axis et Spring 

Dans l'exemple precedent, nous n'avons pas utilise Spring, puisque, pour une couche de 
presentation simple, sans couche de persistance ou metier, cela ne presentait guere 
d'interet. Par ailleurs, cela nous a permis de creer cette application tres rapidement a 
l'aide d'un IDE. 

II est cependant tout a fait possible d'utiliser un service Web a l'interieur d'une applica- 
tion d'entreprise plus complexe. Dans ce cas, Spring propose un systeme simplifiant 
grandement l'acces aux services Web, grace a la classe org.spririgframework.remo- 
ting. jaxrpc. JaxRpcPortProxyFactoryBean. Cette classe permet de transformer un service 
Web en un Bean Spring classique, ne lancant meme pas d'exceptions de type 
java.rmi .RemoteException. 

En voici un exemple d'utilisation simple : 



<bean id="tuduListsServiceLocator" 

cl ass=" tudu. web. ws . axis. Axi sTuduLi stsServi ce Locator "/> 

<bean id="tudul_istsService" 

class="org.springframework.remoting. jaxrpc. 

JaxRpcPort Proxy Factory Bean "> 



Figure 14.2 

Application Swing se 
connectant a Tudu Lists 



ooo 



URL 



http://admin:admin(ffil92. 168.0.2 :8080/tudu/ws/axis/Ti 



Tudu Lists Client 



<property name=" jaxRpcService"> 

<ref bean="tuduListsServiceLocator"/> 
</property> 
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<property name="portName"> 

<val ue>TuduLi stsWebService</val ue> 
</property> 

<property name=" service I nterf ace" > 

<val ue>tudu.web.ws.axis.AxisTuduLists</val ue> 
</property> 
</bean> 

Nous utilisons ici un Bean nomme tuduLi stsServi ceLocator, dont 1' implementation a ete 
generee par les taches Ant d'Axis, et que nous avons deja utilise dans l'exemple Tudu 
Lists Client. 

Ce Bean est utilise par un deuxieme Bean, nomme tuduLi stsServi ce, qui represente notre 
service Web. Ce Bean possede deux autres proprietes : 

• port Name, qui est le nom du port du service Web defini dans le WSDL. 

• servicelnterface, qui est l'interface du service Web que nous avons utilisee depuis le 
debut de cette section. 

II aurait ete tout aussi possible de creer ce Bean sans utiliser de Bean tuduLi stsServi ceLo- 
cator en passant en parametre au Bean tuduLi stsServi ce les proprietes supplementaires 
suivantes : 

• wsdl DocumentUrl , qui est l'URL du WSDL utilise (correspondant a "http:// 
127.0.0.1:8080/Tudu/ws/axis/TuduListswebService?wsdl " dans notre exemple). 

• namespaceUri, qui est l'espace de nommage utilise pour le service Web (http:// 
axis.ws. web. tudu dans notre exemple). 

• serviceName, qui est le nom du service Web ("AxisTuduLi stsServi ce" dans notre 
exemple). 

Nous conseillons cependant l'utilisation de la premiere configuration, avec le Bean tudu- 
Li stsServi ceLocator, car ce dernier est entierement genere par les taches Ant d'Axis, 
reduisant ainsi la complexite de la configuration. 

Le Bean que nous venons de configurer, tuduLi stsServi ce, peut maintenant etre utilise a 
l'interieur de 1' application, comme n'importe quel autre Bean, mais a une difference 
pres : l'interface utilisee, tudu. web. ws. axis. AxisTuduLists, lance des exceptions de type 
java.rmi . RemoteExcepti on. Dans la mesure oil toute methode presentee par un service 
Web lance ce type d' exception, c'est done parfaitement normal. 

Nous pouvons toutefois nous interroger sur le bien-fonde de cette pratique. Du fait de 
cette exception a traiter, le reste de 1' application sait qu'il accede a un service distant, 
chose anormale dans une application decoupee en couches distinctes. Si, par exemple, le 
service metier auquel nous accedons aujourd'hui via un service Web doit etre accessible 
demain via un EJB local, il sera necessaire de recoder les couches superieures de 1' appli- 
cation afin de ne plus traiter les RemoteExcepti on. 

Spring permet de resoudre ce probleme et d' utiliser une interface metier normale, ne 
lanfant pas de RemoteExcepti on, pour acceder a un service Web. Pour cela, la classe Spring 
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que nous venons d'utiliser (JaxRpcPortProxyFactoryBean) est capable de transformer auto- 
matiquement les exceptions de type java.rmi . RemoteException en des exceptions de type 
org.springframework.remoting.RemoteAccessException, qui sont des RuntimeException 
n'ayant pas a etre traitees. 

Pour utiliser cette fonctionnalite, il faut creer une interface identique a celle du service 
Web, mais ne lancant pas de RemoteException, et l'utiliser a la place de l'autre interface 
dans la configuration du Bean, comme ci-dessous : 

<bean id="tuduListsService" 

class="org.springframework.remoting. jaxrpc. 

JaxRpc Port Proxy Factory Bean "> 

<property name=" jaxRpcService"> 

<ref bean="tudul_istsServicel_ocator"/> 
</property> 

<property name="portName"> 

<val ue>Tudul_istsWebService</val ue> 
</property> 

<property name=" service Interfaced 
<val ue>tudu.web.ws .TuduListsWebService</val ue> 

</property> 
</bean> 

Nous utilisons ici l'interface que nous avons definie en debut de chapitre pour l'imple- 
mentation du service Web avec XFire. Nous pouvons ainsi retrouver la me me interface 
metier cote client et cote serveur. 

Ce terme d'« interface metier » est particulierement important. II s'agit reellement d'un 
contrat permettant a un systeme d'utiliser des objets metier presents dans autre systeme, 
et ce sans que ce contrat soit pollue par des contraintes techniques (telles que les exceptions 
de type java.rmi .RemoteException). 



Analyse des echanges SOAP 

Nous venons de detailler deux types de services Web, XFire et Axis, ainsi que la maniere 
d'acceder a ces services, avec ou sans Spring. II est probable qu'a ce niveau du developpe- 
ment nous rencontrions des problemes pour nous connecter a un service Web. Nous allons 
aussi probablement vouloir etudier plus en detail les communications entre notre service 
Web et ses clients a des fins de debogage, d'optimisation ou de calcul du trafic reseau. 

II existe pour cela un outil simple, nomme tcpmon, disponible a l'URL https:// 
tcpmon.dev.java.net. 

tcpmon permet de capturer les echanges reseau entre un client et un serveur, en se posi- 
tionnant en tant que serveur intermediaire. Dans notre exemple, il s'agit de configurer 
tcpmon pour se connecter au serveur (Server Name) 127.0.0.1, sur le port (Server Port) 
8080. tcpmon redirige alors les requetes et les reponses echangees avec ce serveur sur le 
port (Local Port) 8081. 
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Ainsi, pour se connecter au service Web que nous avons developpe, nous utilisons le port 
8081 pour passer par tcpmon : 

http://127. 0. 0. 1 :808 1/Tudu/ws/axis/TuduLists WebService 

Nous pouvons de cette maniere etudier les echanges SOAP entre Tudu Lists et le client 
Swing. 

La figure 14.3 illustre une analyse par tcpmon des echanges entre en client et un serveur 
SOAP, en l'occurrence l'application Tudu Lists Client accedant a un serveur Tudu Lists 
et effectuant une demande d' envoi de 1' ensemble des listes de todos grace a la methode 
getAllTodoLists. 



Figure 14.3 

Utilisation de tcpmon 
pour etudier les flux 
SOAP 



ooo 
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xmlns:soapenv="http://schemas. xmlsoap.org/ soap/ envelope/" 
xmlns:xsd="http:// www.w3.org/2001/XMLSchema" 
xmlns:xsi="http:// www.w3.org/ 2001 /XMLSchema-instance"xsoapenv: 
Bodyxnsl getAllTodoLists 

soapenv:encodingStyle="http:// schemas.xmlsoap.org/ soap/encoding/" 
xmlns:nsl="http://axis.ws .web. tudu"/ ></soapenv Bodyx/soapenv En 
velope> 



<?xml version="1.0" encoding="utf-8"?xsoapenv:Envelope 
xmlns:soapenv="http://schemas. xmlsoap.org/ soap/envelope/" 
xmlns:xsd="http:// www.w3.org/2001/XMLSchema" 
xmlns:xsi="http:// www.w3.org/ 200 l/XMLSchema-instance"xsoapenv: 
Bodyxnsl getAIITodoListsResponse 

soapenv:encodingStyle="http:// schemas.xmlsoap.org/ soap /encoding/" 
xmlns:nsl="http//axis.ws.web.tudu"xgetAIITodoListsReturn 



, a " 



Ce logiciel presente, dans sa zone de texte superieure, la requete envoyee, et, dans sa 
zone de texte inferieure, la reponse retournee par le serveur. Le format SOAP etant assez 
facilement comprehensible, cette methode permet de comprendre les problemes d'intero- 
perabilite que nous ne manquons pas de rencontrer entre un client et un serveur codes 
avec des frameworks differents. 
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Conclusion 

Ce chapitre a montre comment publier des Beans Spring grace aux technologies XML 
disponibles et creer ainsi des applications en mode SOA. 

Nous avons vu qu'il etait relativement simple de developper nous-meme notre propre 
format XML, avec JDOM, ou d'utiliser le format RSS. 

Nous avons egalement detaille deux implementations Open Source nous permettant de 
realiser des services Web : 

• XFire, un framework tres bien integre a Spring, rapide d'utilisation, performant et effi- 
cace, mais manquant de maturite et de reconnaissance. 

• Axis, un framework assez bien integre a Spring, robuste, fiable et tres largement 
utilise, mais souffrant de certaines lourdeurs, qui affectent le developpement, et de 
lenteur lors de son execution. 

Tout au long de ce chapitre, nous avons vu que l'utilisation d'un format XML etait tres 
differente de l'utilisation directe d'un objet Java. De nombreux problemes de perfor- 
mance et de mappage objet/XML limitent l'utilisation de cette solution au strict neces- 
saire. 

N'oublions pas la premiere regie concernant les objets distribues enoncee par Martin 
Fowler: « N'utilisez pas d'objets distribues ! », puisqu'il s'agit d'une des premieres 
causes de lenteur des applications. 

Pour une application Spring typique, et done proprement decoupee en couches, l'utilisa- 
tion d'une couche de publication d'objets en XML represente reellement une couche de 
presentation specifique, dont le role est la simple publication d'objets metier. II est possi- 
ble d'aj outer des services Web a une application existante et de les proposer en comple- 
ment d'autres methodes : acces local aux objets et RMI en particulier. Cela permet 
d'utiliser XML et les services Web de facon raisonnee, en n'utilisant ces derniers que 
lorsqu'ils sont reellement necessaires. 

Nous avons volontairement passe sous silence 1' aspect securite, car il fait 1' objet du 
chapitre suivant, dans lequel nous montrons comment utiliser Acegi Security pour ajouter 
une authentification HTTP aux services Web que nous venons de developper. 
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La securite 
avec Acegi Security 



Sur Internet, mais aussi au coeur meme d'une entreprise, le risque de compromission de 
donnees sensibles peut conduire a des catastrophes en termes economiques ou legaux. La 
securite est done un aspect important du developpement d'une application. Sujet 
complexe, s'il en est, elle ne doit pas etre traitee a la legere. Pour ces raisons, ce chapitre 
commence par rappeler les besoins couramment exprimes en matiere de securite, ainsi 
que les concepts cles generalement utilises dans ce domaine. 

En Java, nous disposons de JAAS (Java Authentication and Authorization Service) et de 
la specification J2EE pour nous aider dans cette tache. II s'agit de standards largement 
utilises, qu'il est important de connaitre, puisqu'un grand nombre de solutions s'appuient 
dessus. D'une maniere plus generale, leur maitrise est un prerequis a l'utilisation de 
frameworks plus complexes. Nous verrons les limitations de ces deux specifications et 
les raisons pour lesquelles elles ne sont pas suffisantes pour developper des applications 
d'entreprise un tant soit peu complexes. 

Acegi Security est un projet Open Source qui propose une solution de securite integree 
complete aux systemes utilisant Spring. Tres largement utilisee au sein de la commu- 
naute Spring, elle peut de facto etre consideree comme un standard. Nous detaillons dans 
ce chapitre les principes de fonctionnement et 1' API d' Acegi Security et insistons sur les 
avantages qu'elle procure par rapport aux autres solutions. 

En suivant notre etude de cas, nous verrons de quelle maniere utiliser Acegi Security afin 
d'obtenir une solution de securite simple mais suffisante dans la majorite des cas pour 
gerer un formulaire de login, securiser des services Web et gerer des droits d'utilisateur 
et des login automatises en fonction d'un cookie. 
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La securite dans les applications Web 

Cette section rappelle les besoins habituellement exprimes pour la securisation d'une 
application, ainsi que les concepts utilises pour repondre a ces besoins. Nous pourrons de 
la sorte mieux comprendre les specificites fonctionnelles et techniques induites par la 
securite. 

Nous nous interesserons en particulier aux applications d'entreprise, et plus specifiquement 
aux applications Web fondees sur J2EE, qui sont la cible meme de cet ouvrage. 



Les besoins 

La grande majorite des applications ont les memes besoins en terme de securite. C'est 
d'ailleurs pour cette raison que la creation d'un mecanisme specifique de gestion de la 
securite est une aberration et que l'utilisation d'un framework preexistant est largement 
preferable. 

Gestion des utilisateurs 

Les utilisateurs, leur mot de passe et leurs droits doivent etre geres dans un systeme 
specialise. Dans les entreprises, il est courant que ce systeme soit un referentiel centra- 
lise, tel un annuaire LDAP. II s'agit d'une sorte de base de donnees optimisee pour les 
requetes en lecture et possedant une structure arborescente permettant de stacker des 
hierarchies. Nous rencontrons aussi des systemes plus simples, reposant sur des bases de 
donnees relationnelles. Nous abordons ces dernieres en detail dans notre etude de cas. 

Ces systemes ont, de preference, les caracteristiques suivantes : 

• Gestion d'attributs lies a l'utilisateur (nom, numero de telephone, etc.). 

• Verification du mot de passe. II est preferable qu'un systeme externe gere les mots de 
passe, plutat que chaque application utilisatrice. 

• Gestion des droits des utilisateurs. 

• Gestion des groupes d'utilisateurs, qui facilite la gestion des droits. 

II va de soi que les entreprises ne fournissent pas toujours un systeme de gestion des 
droits aussi complet. Les developpeurs doivent regulierement faire face a des situations 
degradees, dans lesquelles certains de ces besoins ne peuvent etre pris en compte ou 
doivent etre developpes specifiquement. 

Securisation des URL 

La securisation la plus simple a mettre en place est celle des requetes HTTP. Nous deci- 
dons de ne permettre qu'a un certain type d'utilisateur d'acceder a une URL donnee. 
Dans Tudu Lists, par exemple, les URL se terminant par /secure/** sont reservees aux 
utilisateurs authentifies et possedant le role ROLEJJSER. 
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Ce type de securisation peut etre mis en place aux niveaux suivants : 

• Reseau, avec utilisation d'un repartiteur de charge (de type Alteon). 

• Serveur Web, avec, par exemple, utilisation de la securite dans Apache. 

• Serveur J2EE, que nous detaillons plus en detail par la suite, car il propose une integration 
bien plus avancee de la securite au sein de 1' application developpee. 

Notons que le principal defaut de cette solution est qu'il est necessaire de disposer d'une 
bonne strategie dans le nommage des URL. Cette politique contraignante est difficile - 
ment imposable a une application existante. C'est pourquoi elle doit etre mise en place 
des la conception de 1' application. 

Securisation de la couche de service 

La couche de service n'est normalement pas accessible aux utilisateurs finals de l'appli- 
cation. Cependant, le fait de securiser des EJB Session ou des Beans Spring presente un 
double interet : 

• Cela renforce la securite de l'application en empechant un utilisateur malveillant d'y 
avoir acces. Si un service est sensible et ne doit etre utilise que par 1' administrate ur, 
mieux vaut valider qu'il ne peut etre execute que par des personnes ayant le role 
adequat. 

• Cela permet 1' acces distant a ces objets. II est ainsi possible de permettre a des appli- 
cations externes d'utiliser un service sensible, a condition que leurs utilisateurs soient 
dument autorises a y acceder. 

Cette securisation peut se faire au niveau d'une classe ou d'une methode. 
Securisation des objets de domaine 

Plus rarement exprime, ce besoin consiste a securiser certaines instances d' objets metier. 
Dans l'exemple de Tudu Lists, un utilisateur a le droit d'effacer des todos mais ne doit 
pouvoir effacer que les todos qui lui appartiennent. II a done le droit d'executer la 
methode de suppression des donnees (securisation de la couche de service), mais pas sur 
1' ensemble des objets metier. 

Ce besoin se fait sentir dans la plupart des applications multiutilisateurs. Dans une boutique 
en ligne, par exemple, un utilisateur n'a le droit de gerer que son panier d' achat. 

Nous verrons cependant dans la suite de ce chapitre que cette securisation est generalement 
un luxe inutile. 



Controle du code execute 

Ce besoin, qui se rencontre egalement rarement dans le cadre d'une application Web 
J2EE, consiste a n'autoriser l'execution que de code qui a ete valide. L'exemple le plus 
courant est celui des applets. Dans la mesure ou nous executons du code telecharge 
depuis Internet, nous ne pouvons avoir une confiance absolue dans ce programme. 
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Dans le cadre d'une application Java/J2EE s' executant sur un serveur d'entre prise, il 
n'est pas utile de prendre en compte ce type de consideration. Si une personne 
malveillante accede au serveur et est capable d'intervenir directement sur du code, elle 
sera egalement capable d'en modifier les regies de securite. Mieux vaut done mettre 
P accent sur la securisation des serveurs (et de leurs locaux) et eviter ce type de 
complexite aux developpeurs d' applications. 

Rappel des principales notions de securite 

La securite s'appuie sur deux notions principales, Pauthentification des utilisateurs et la 
gestion de leurs autorisations, auxquelles se greffe un vocabulaire specialise, que nous 
allons rappeler : 

• Authentification. Verification qu'un utilisateur est bien la personne qu'il pretend etre. 
Cette verification s'effectue generalement a Paide d'un couple identifiant/mot de passe. 

• Autorisation. Verification qu'un utilisateur authentifie a la permission de realiser une 
action. Un utilisateur possede generalement un ensemble d' autorisations, qui peuvent 
etre gerees par groupes pour plus de facilite. 

• Les objets Subject et Principal. Specifiques de Java, ces objets se retrouvent dans 
P ensemble des implementations que nous allons etudier par la suite. Un Subject repre- 
sente un utilisateur, tel qu'il est vu par Papplication en cours. Ce Subject peut posseder 
plusieurs Principal, chacun de ces objets etant une representation de cette personne. 
Login, numero de Securite sociale et adresse e-mail peuvent etre autant de Principal 
d'un meme Subject. 

• Ressources et permissions. Une ressource represente une entite protegee. II peut 
s'agir d'un fichier, d'une URL ou d'un objet. Une permission correspond au droit 
d'acceder a cette ressource. Pour qu'un utilisateur accede a une URL protegee, il faut 
que ses autorisations lui donnent la permission d'y acceder. 

La securite Java 

Java propose deux API pour gerer la securite : JAAS, pour les projets Java standards 
(J2SE), et une API specifique incluse dans la norme J2EE. 

Nous allons voir que ces API ne repondent que de maniere fragmentaire aux besoins que 
nous avons rappeles precedemment. II est cependant essentiel de les connaitre, car elles 
composent le socle technique standard de J2EE. 

JAAS 

JAAS (Java Authentication and Authorization Service) a ete integre a J2SE 1.4, apres 
avoir ete un package optionnel. 
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II s'agit d'une API de bas niveau, permettant en particulier de gerer les privileges du code 
qui s' execute. Peu adaptee a une application Java/J2EE, elle s'adresse a un domaine 
different : les applets et les applications graphiques autonomes fondees sur AWT ou 
Swing. 

La gestion des utilisateurs en base de donnees ou la creation de formulaires Web de login 
sont des sujets bien eloignes de cette specification, qui n'est pas concue pour cela. Par 
ailleurs, les fonctionnalites qu'elle propose en matiere de gestion des privileges d'execution 
du code ne correspondent pas a une application Web classique. 

Nous ne nous attarderons done pas sur cette specification et nous pencherons plutot sur 
les extensions specifiques a J2EE. 

La specification J2EE 

La specification J2EE inclut plusieurs objets et methodes dedies a la securite. Generale - 
ment simples, ces derniers ont l'avantage d'etre bien integres dans les frameworks existants. 
Struts, par exemple, utilise cette API. 

Si cette specification pose un certain nombre de problemes, que nous allons detailler, elle 
n'en presente pas moins le grand avantage d'etre un standard officiel. 

Les servlets 

La specification servlet permet de definir des regies de securite au niveau du fichier 
WEB-INF/web.xml afin de proteger des URL en fonction de leur nom. Elle supporte des 
methodes d'authentification simples (par formulaire, authentification HTTP basique ou 
certificat) et fournit une API rudimentaire. Cette API se trouve essentiellement dans deux 
methodes de l'objet javax. servlet. http.HttpServletRequest : 

• getRemoteUser( ), qui permet d'obtenir le login de l'utilisateur en cours sous forme de 
chaine, a charge pour le developpeur d'appeler la couche de service de son application 
pour retrouver un objet representant l'utilisateur en fonction de ce login. 

• isUserInRole(String role), qui verifie si l'utilisateur en cours possede l'autorisation 
demandee. II est ainsi facile de verifier si l'utilisateur a le role « administrateur » et de 
lui afficher un ecran specifique d' administration. 

Ces deux methodes aussi simples qu'efheaces sont sufhsantes pour des applications Web 
peu complexes. 

La specification dans son ensemble souffre toutefois d'un grand nombre d'inconvenients : 

• Elle n'est pas portable d'un serveur d' applications a un autre, chaque serveur J2EE en 
possedant sa propre implementation. Dans le meilleur des cas, migrer vers un nouveau 
serveur peut simplement consister en une configuration specifique de ce module, mais 
cela peut etre nettement plus complique. 
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• La gestion des URL dans le fichier WEB -INF/we b.xml est rudimentaire. II n'est pas 
possible, par exemple, d'utiliser des expressions regulieres pour definir une URL. 

• Les services fournis sont generalement elementaires. II n'y a pas de service d'authen- 
tification automatique par cookie, par exemple, ni de systeme pour empecher deux 
utilisateurs d'utiliser le meme login en meme temps, etc. 

• Cette specification reposant sur l'objet HttpServl etRequest, elle requiert la presence de 
cet objet et n'est done utilisable qu'au plus pres de la couche de presentation. Elle pose 
en outre des problemes en matiere de tests unitaires puisqu'il faut simuler cet objet. 

Les EJB 

Les EJB mettent en ceuvre une API similaire a celle des servlets et proposent ainsi une 
securite au niveau des classes et des methodes de la couche de service. L'interet de cette 
securite est qu'elle se propage depuis 1' application Web (ou le client Swing) a 1' ensemble 
des EJB utilises. 

Le fait de pouvoir securiser des EJB au niveau de leur classe comme de leurs methodes, 
via le fichier ejb-jar.xml, offre une grande finesse a la politique de securite. Le nom de 
l'utilisateur et ses roles peuvent etre utilises de la meme maniere que pour les servlets, 
via les methodes getCallerPrincipal ( ) et isCallerlnRoleO de l'objet javax.ejb.EJB- 
Context. 

Cette API etant proche de l'API servlet, elle en conserve le vice originel, et les applica- 
tions ainsi developpees sont generalement difficiles a porter d'un serveur d' applications 
a un autre. 

Utilisation d'Acegi Security 

Acegi Security est un framework Open Source dont l'objectif est de proposer un systeme 
complet de gestion de la securite. II peut etre utilise de maniere independante mais fonc- 
tionne de maniere optimale avec Spring. II s'agit d'ailleurs d'une solution tres repandue 
au sein de la communaute Spring. 

Cette section presente les avantages fournis par Acegi Security par rapport a une solution 
J2EE classique. Nous verrons aussi comment 1' installer et le configurer. 

Acegi Security est disponible a l'adresse http://acegisecurity.sourceforge.net/. 

Principaux avantages 

Le premier avantage d'Acegi Security est sa portability. Ne dependant pas d'un serveur 
d' applications particulier, son utilisation est identique quel que soit le serveur utilise. 
C'est grace a cela que Tudu Lists peut etre utilise sans reconfiguration sur Tomcat, JBoss, 
Geronimo ou WebLogic. 
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Cette portability est particulierement importante si 1' application developpee doit pouvoir 
etre vendue a un grand nombre de clients possedant des systemes heterogenes. Dans le 
cadre d'une application developpee en interne, il n'en reste pas moins dommage de se 
trouver bloque sur un serveur d' applications uniquement a cause d'une problematique de 
securite. 

Le deuxieme avantage d'Acegi Security est qu'il fournit en standard un nombre de fonc- 
tionnalites beaucoup plus important qu'un serveur J2EE classique. Parmi les plus 
simples, et qui manquent cruellement dans la specification J2EE, citons 1' authentication 
automatique par cookie pour un nombre donne de jours, ainsi que la verification qu'un 
utilisateur n'est pas deja authentifie avec le login demande. 

Acegi Security propose en outre des fonctionnalites avancees, telles que le Single Sign- 
On (une authentification unique pour l'ensemble des applications de l'entreprise) ou la 
securisation des objets de domaine, fournissant ainsi une aide considerable au developpement 
d' applications ayant des besoins complexes en matiere de securite. 

Enfin, Acegi Security propose une excellente integration avec les applications Web et les 
Beans Spring. Concernant les applications Web, il propose des filtres de servlets bien 
plus fins que ceux proposes par la norme J2EE. Pour les Beans Spring, il permet d'utiliser 
la POA afin de securiser la couche metier de maniere efhcace et transparente. 

Si nous reprenons les besoins de securite rappeles en debut de chapitre, Acegi Security 
apporte les avantages suivants : 

• Gestion des utilisateurs : solution integree, complete et portable. 

• Securisation des requetes HTTP : disponible de maniere plus fine que dans la norme 
J2EE. 

• Securisation de la couche de service : API complete, qui s'integre dans les frameworks 
courants de POA (AOP Alliance, une API implementee par Spring AOP, et AspectJ). 

• Securisation de la couche de domaine : listes de controle d'acces, qui peuvent etre 
specifiers au niveau de chaque objet de domaine. 

• Controle du code execute : non pris en compte par Acegi Security. Comme nous 
l'avons vu, cette fonction est rarement utile dans une application d'entreprise. 



Installation 

Acegi Security se compose d'un fichier JAR principal et necessite la presence d'un 
certain nombre de dependances. Ces differents JAR sont fournis dans 1' application exem- 
ple livree avec Acegi Security, ainsi que dans Tudu Lists. Acegi Security utilisant Maven, 
une bonne maniere d'etudier ces JAR est de passer en revue le rapport Maven de gestion 
des dependances, disponible dans la documentation du framework. 

Une fois ces bibliotheques deposees dans le repertoire WEB-INF/lib, la configuration 
d'Acegi Security s'effectue via le descripteur de deploiement et la configuration Spring. 
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Dans le fichier WEB-INF/web.xml, nous definissons un filtre de servlets, qui sera 
responsable de la securite de 1' application (Acegi Security propose en interne des nitres 
bien plus fins que ceux proposes par la specification J2EE) : 

<filter> 

<filter-name>Acegi Security Filter</filter-name> 
<filter-class> 

org. acegi security. uti 1 . Fi 1 terToBean Proxy 
</f i 1 ter-cl ass> 
<init-param> 

<param-name>targetCl ass</param-name> 

<param-val ue> 
o rg. acegi security .uti 1 .FilterChainProxy 

</param-val ue> 
</init-param> 
</filter> 

( ... ) 

<filter-mapping> 

<filter-name>Acegi Security Filter</filter-name> 

<url -pattern>/*</url -pattern> 
</filter-mapping> 

Cette configuration redirige l'ensemble des requetes HTTP vers Acegi Security. 

Contexte de securite et f litres 

Acegi Security fournit un certain nombre de Beans Spring, qu'il s'agit de relier entre eux 
via une configuration Spring classique. 

Dans Tudu Lists, nous avons opte pour un fichier separe du reste de la configuration 
Spring (WEB-INF/applicationContext-security.xml). Nous recommandons cette pratique, 
car ce fichier va avoir une taille assez consequente. 

A la base du fichier de configuration se trouve la classe donnee en parametre au filtre 
defini precedemment, org. acegi security .uti 1 . FilterChainProxy. Cette classe a pour fonc- 
tion de traiter les requetes HTTP avec des filtres fournis par Acegi Security. II s'agit d'un 
filtre HTTP unique, defini dans le descripteur de deploiement de l'application Web, qui 
renvoie vers des filtres specifiques traites en interne par Acegi Security. 

Cette manoeuvre permet de simplifier la configuration du descripteur de deploiement en 
realisant la vraie configuration des filtres de securite dans le contexte Spring. Cela offre 
une configuration plus fine qu'avec le standard J2EE. 

Cette classe permet de lier les filtres de securite de la maniere suivante (tiree de Tudu 
Lists) : 

<bean id="filterChainProxy" 

class= "org. acegi security. uti 1 . Fi IterCha in Proxy "> 
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<property name="f i 1 terlnvocationDef initionSource"> 
<val ue> 

CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 
PATTERN_TYPE_APACHE_ANT 

/secure/**=httpSessionContext Integration Filter, 

contextHol derAwareRequestFil ter , 

rememberMeProcessingFilter, 

securityEnforcementFilter 
/j_acegi_security_check*= 

httpSessionContext Integration Filter, 

authenticationProcessingFi 1 ter 
/welcome. action= 

httpSessionContext Integration Filter, 

contextHol derAwareRequestFil ter , 

rememberMeProcessingFi 1 ter 

</val ue> 
</property> 
</bean> 

Pour des raisons de lisibilite, nous avons ajoute des retours chariot, mais chaque liste de 
nitres, separes par des virgules, vient normalement sur une seule ligne. 

Nous voyons dans cet exemple que les URL vont etre validees suivant leur nom en 
minuscule (premier parametre) et avec une expression reguliere de validation de type Ant 
(deuxieme parametre). Ant est un outil de construction de code tres populaire (disponible 
a l'adresse http://ant.apache.org/), dont les motifs de validation sont plus efficaces que ceux 
du standard J2EE. 

Nous pouvons ainsi valider des URL telles que /secure/catalogue/admin et /secure/paie- 
ment /admin en utilisant le motif "/secure/**/admin/", ce qui ne serait pas possible en mode 
standard. 

Dans 1' exemple, nous voyons trois URL, auxquelles sont appliques un certain nombre de 
filtres. Ces filtres ont un ordre defini, qu'il est important de respecter. 

Voici l'ordre d'utilisation des nitres fournis par Acegi Security : 

1. Channel ProcessingFi Iter : permet de rediriger l'URL vers un autre protocole (essen- 
tiellement de HTTP vers HTTPS). 

2. ConcurrentSessionFilter : verifie si l'utilisateur en cours n'a pas deja une session 
ouverte, et, si oui, bloque la requete afin d'eviter d'avoir deux utilisateurs authentifies 
par un meme login. 

3. HttpSessionContextlntegrationFilter : permet de stacker le contexte de securite 
d' Acegi Security dans la session utilisateur. II est essentiel d'avoir ce filtre en place 
pour qu' Acegi Security puisse fonctionner. 

4. Filtres d'authentification, tels que AuthenticationProcessingFilter. Dans l'exemple 
ci-dessus, ce filtre n'est utilise que sur les URL servant a authentifier un utilisateur. 
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5. ContextHolderAwareRequestFilter : permet d'utiliser 1' API servlet standard pour gerer 
la securite, par exemple les methodes getRemoteUser ou i sUserlnRol e. 

6. RememberMeProcessingFilter : gere l'authentification automatique des utilisateurs en 
fonction d'un cookie. 

7. AnonymousProcessingFilter : si, a la suite des nitres precedents, l'utilisateur n'est 
toujours pas authentifie, ce nitre lui donne une authentification anonyme. 

8. SecurityEnforcementFilter : protege les URL. Si un utilisateur n'est pas authentifie 
ou n'a pas les bonnes autorisations, ce nitre rejette ses requetes. 

Comme nous avons pu le voir dans l'exemple, nous n'utilisons generalement pas 
l'ensemble de ces nitres. Seuls trois d'entre eux sont necessaires pour utiliser Acegi 
Security de maniere simple: HttpSessionContextlntegrationFilter, AuthenticationPro- 
cessingFilter et SecurityEnforcementFilter. Nous les presentons plus en detail dans les 
sections suivantes. 



Gestion de l'authentification 

Acegi Security propose plusieurs nitres d' authentification, par exemple Jbosslntegra- 
ti on Filter, pour que l'authentification soit geree en interne par le serveur JBoss, mais le 
filtre normalement utilise est AuthenticationProcessingFilter. 

Ce filtre offre un grand nombre d' options de configuration, dont nous ne presentons que 
les principales. En voici une configuration simple : 

<bean id= "authentication Processing Filter" 
cl ass= 

"org. acegi security .ui .webapp.AuthenticationProcessingFil ter"> 

<property name="authenticationManager"> 
<ref bean="authenticationManager" /> 
</property> 

<property name="authenticationFailureUrl "> 

<val ue>/wel come. act i on? 1 ogin_error=true</val ue> 
</property> 

<property name="defaultTargetUrl "> 

<val ue>/secure/showTodos . action</val ue> 
</property> 

<property name="filterProcessesUrl "> 

<val ue>/j_acegi_securi ty_check</val ue> 
</property> 
</bean> 

<bean id="authenticationManager" 

class= "org. acegi security.providers.ProviderManager"> 
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<property name="providers"> 
<11st> 

<ref local="authenticationProvider" /> 
</list> 
</property> 
</bean> 

Les trois proprietes les plus courantes du Bean authenti cationProcessingFi Iter sont les 
suivantes : 

• authenti cationFail ureUrl : URL vers laquelle l'utilisateur est redirige en cas d'erreur 
d'authentification. Dans cet exemple, on ajoute un parametre a la requete de maniere a 
afficher un message d'erreur sur la page d'accueil. 

• def aul tTargetUrl : URL vers laquelle l'utilisateur est redirige par defaut si son authen- 
tification reussit. 

• filterProcessesUrl : URL utilisee pour traiter l'authentification. 

L'authentification a proprement parler est deleguee a un deuxieme Bean, authenti cati on- 
Manager. Ce dernier liste un certain nombre de methodes d'authentification. Dans notre 
cas, il n'y en a qu'une, qui correspond de loin au cas le plus courant, mais il pourrait y 
avoir plusieurs objets a la suite, chacun gerant un type d'authentification different. 

Nous allons maintenant aborder les deux methodes d'authentification les plus couram- 
ment utilisees : via la base de donnees et via un serveur LDAR Une authentification 
specifique sera realisee dans le cadre de 1' etude de cas. 

Authentification via une base de donnees 

Si P application que nous developpons n'est pas connectee a un systeme de securite 
fourni par Pentreprise, le plus simple est de stacker les donnees d'authentification au sein 
de la base de donnees. 

Pour ce faire, Acegi Security propose un schema de base de donnees par defaut. Si ce dernier 
ne convient pas aux besoins, le DAO utilise pour Pinterroger est entierement configurable : 

<bean id=" authenti cat ion Provider" 

cl ass=" org. acegi security.providers.dao.DaoAuthenticationProvider"> 

<property name="userDetai 1 sService"> 
<ref local="userDetailsService" /> 
</property> 
</bean> 

<bean id="userDetailsService" 

cl ass="org. acegi securi ty . userdetail s . jdbc. JdbcDaoImpl "> 



<property name="dataSource"> 

<ref bean="dataSource"/> 
</property> 
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<property name="usersByUsernameQuery"> 
<val ue> 

SELECT login, password, enabled FROM user WHERE login = ? 
</val ue> 
</property> 

<property name="authoritiesByUsernameQuery"> 
<val ue> 

SELECT login, role FROM role WHERE login = ? 
</val ue> 
</property> 
</bean> 

Dans cet exemple, la premiere requete doit retourner trois valeurs : le login, le mot de 
passe et si l'utilisateur est active ou non. La seconde requete a pour but de retrouver des 
couples login-role, un utilisateur pouvant avoir plusieurs roles. 

Ces requetes doivent permettre de mapper tout type de schema de base de donnees sur ce 
DAO. Si cela n'est toujours pas suffisant, il reste possible de configurer encore plus fine- 
ment cet objet. Cela necessite toutefois de connaitre un peu iBATIS, un outil de mappage 
objet/relationnel utilise en interne dans Acegi Security, ou de construire notre propre 
DAO. Nous verrons cette derniere option a la section consacree a 1' etude de cas. 

Authentification via LDAP 

Les annuaires LDAP sont aujourd'hui de plus en plus repandus en entreprise. Acegi 
Security propose un type d'authenticationProvider specifique pour acceder a un serveur 
LDAP. II se configure de la facon suivante : 

<bean id="initialDirContext Factory" 

class= "org. acegi security.providers.l dap. 

Defaul tlniti al Di rContext Factory "> 



<constructor-arg 

val ue="ldap://serveurl dap:389/dc=exempl e,dc=com"/> 

<property name="managerDn"> 

<val ue>cn=manager ,dc=exeinpl e ,dc=com</val ue> 
</property> 

<property name= "manager Password" > 

<val ue>password</val ue> 
</property> 




</bean> 



<bean id=" authentication Provider" 

class= "org. acegi security.providers.l dap. 



LdapAuthenticationProvider"> 



<constructor-arg> 
<bean class= "org. acegi security.providers.l dap. 

authenticator.BindAuthenticator"> 
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<constructor-arg> 

<ref local =" initial Di rContext Factory "/> 
</constructor-arg> 
<property name="userDn Patterns'^ 

<list> 

<val ue>uid={0} ,ou=peopl e</val ue> 
</list> 
</property> 
</bean> 
</constructor-arg> 
<constructor-arg> 
<bean class= "org. acegi security.providers.l dap. 

popul ator .Defaul tLdapAuthori tiesPopul ator"> 

<constructor-arg> 

<ref local =" initial Di rContext Facto ry"/> 
</constructor-arg> 
<constructor-arg> 

<val ue>ou=groups</val ue> 
</constructor-arg> 
<property name="groupSearchFi 1 ter"> 

<val ue>(member={0} )</val ue> 
</property> 

<property name="groupRoleAttribute"> 

<val ue>cn</val ue> 
</property> 

<property name="rolePrefix"> 

<value>ROLE_</value> 
</property> 

<property name="convertTollpperCase"> 

<val ue>true</val ue> 
</property> 
</bean> 
</constructor-arg> 
</bean> 

Cette configuration utilise deux Beans Spring specifiques, qui utilisent tous deux l'injec- 
tion de dependances par constructeur, contrairement au reste d' Acegi Security, qui utilise 
la plus conventionnelle injection de dependances par modificateur. 

Le premier Bean, i ni ti al Di rContextFactory, represente un gestionnaire de connexions au 
serveur LDAP (utilisant le design pattern fabrique), qui prend en parametre le Distin- 
guished Name et le mot de passe d'un administrateur. C'est grace a ce JavaBean que nous 
pouvons obtenir des connexions au serveur LDAP dans le second Bean. 

Ce dernier correspond a une nouvelle configuration de authenticationProvider, qui utilise 
cette fois une classe specifique pour la connexion LDAP. II est lui-meme construit a 
l'aide des deux JavaBeans suivants : 

• La classe BindAuthenticator, qui permet de Her un utilisateur au serveur LDAP. C'est 
grace a elle que le serveur LDAP authentifie l'utilisateur en fonction de son Distin- 
guished Name et de son mot de passe. Le Distinguished Name est retrouve grace aux 
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requetes passees en parametres dans userDnPatterns. Dans notre exemple, nous utilisons 
{0} pour passer en parametre le login de l'utilisateur. 

• Laclasse DefaultLdapAuthoritiesPopul ator, qui permet de retrouver les autorisations de 
l'utilisateur. Le constructeur de cette classe prend en parametre le Distinguished Name 
contenant les groupes (ou=group dans l'exemple). II utilise un certain nombre de 
proprietes, que nous avons laissees a leurs valeurs par defaut dans l'exemple. Acegi 
Security recherche tous les groupes dont l'utilisateur est membre (la propriete group- 
SearchFilter prenant en parametre le login de l'utilisateur), les met en majuscules et 
les prefixe de ROLE. Un utilisateur membre du groupe « admin » a done un role 
R0LE_ADMIN. 

Relativement complexe, cette configuration devrait neanmoins permettre d'integrer 
Acegi Security avec tout type d'arborescence LDAP. 



Gestion des autorisations 

Dans Acegi Security, la permission d'acceder a une ressource est decidee par un systeme 
de vote. 

Cette ressource peut etre protegee de deux manieres : par la securisation des URL utili- 
sant cette ressource ou par programmation orientee aspect, ou POA. Nous allons detailler 
la configuration et le fonctionnement de ces deux systemes. 

Le systeme de vote 

Ann de determiner si un utilisateur a le droit d'acceder a une ressource, Acegi Security 
utilise un systeme de votes grace a la classe essentielle org. acegi security .vote. Rol eVoter. 
Cette classe valide l'acces a une ressource en fonction des roles possedes par l'utilisateur. 
Elle se configure dans le fichier WEB-INF/applicationContext-security.xml : 

<bean id="roleVoter" class= "org. acegi security. vote. Rol eVoter"> 

<property name="rolePrefix"> 
<value>ROLE_</value> 

</property> 
</bean> 

Notons que cette classe ne vote que pour les ressources protegees par un role ayant un 
prefixe donne (R0LE_ par defaut). 

Etant donne que plusieurs de ces Beans de vote peuvent etre utilises pour proteger une 
ressource, plusieurs votes sont emis pour autoriser l'acces a une ressource donnee. 

Le traitement des votes est effectue par un autre Bean, qui utilise l'interface org. acegi se- 
curity, vote. AccessDecisionVoter. II en existe trois implementations differentes, en fonc- 
tion de la maniere dont nous souhaitons traiter les votes. Elles sont contenues dans le 
package org. acegisecurity. vote : 

• Af f i rmati veBased : donne l'autorisation d'acceder a la ressource si l'un des votants au 
moins a donne son accord. 
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• ConsensusBased : donne l'autorisation si la majorite des votants est d'accord. 

• UnanimousBased : donne l'autorisation uniquement si l'ensemble des votants est 
d'accord. 

L' implementation selectionnee pour gerer les votes est egalement configuree dans WEB- 
INF/applicationContext-security.xml : 

<bean id="accessDecisionManager" 

cl as s=" org. acegi security .vote. Affi rmati veBased"> 

<property name="al lowIfAl 1 AbstainDecisions"> 

<val ue>fal se</val ue> 
</property> 

<property name="deci sionVoters"> 
<list> 

<ref 1 ocal ="rol eVoter" /> 
</list> 
</property> 
</bean> 

Comme nous pouvons le voir dans cette configuration tiree de Tudu Lists, ce Bean utilise 
le Bean roleVoter, que nous avons vu precedemment. Etant donne que, dans notre cas, il 
n'y a qu'un seul votant, le choix du Bean access DecisionManager n'est au final pas tellement 
important. 

Le systeme de vote presente ici autorise des configurations extremement sophistiquees. 
Cependant, dans la pratique, nous n'avons souvent qu'un seul Bean votant, ce qui simpli- 
fie grandement les problemes. C'est cette configuration, la plus courante, que nous avons 
presentee dans le code de nos deux Beans. 

Securisation des URL 

Nous avons deja rencontre dans ce chapitre des exemples d'URL protegees avec Acegi 
Security. D'une maniere similaire a la specification J2EE, Acegi Security permet de 
proteger des URL en fonction de leur nom. L'utilisation d'Acegi Security offre cepen- 
dant un avantage decisif : son nitre propose l'utilisation d'expressions regulieres de type 
Ant, bien plus puissantes que leurs rivales de la specification J2EE. 

Ce type de securisation necessite une planification prealable, afin de definir a l'avance 
quels types d'URL seront proteges et avec quels roles. II faut done fournir un travail 
de specification des URL lors de la phase de conception du logiciel. Les motifs 
d'URL generalement utilises sont de type /secure/administrateur/** ou /secure/**/ 
responsabl e_commerci al /**. 



Cette methode est de loin la plus repandue et reste generalement simple d'utilisation. 
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Utilisation de la POA 

II existe des besoins trop complexes pour etre geres via une securisation d'URL. Imagi- 
nons, par exemple, une application de vente de produits sur Internet. Les utilisateurs 
finals de 1' application n'ont aucun droit en ecriture sur le catalogue produit. Nous 
voudrions etre certains qu'un utilisateur ne puisse jamais acceder a une methode de mise 
a jour d'un produit. Or, de maniere classique, il n'est pas possible de repondre a ce 
besoin. Nous allons avoir que la programmation orientee aspect le permet. 

Acegi Security s'integre aux specifications de l'AOP Alliance (implementee en parti- 
culier par Spring AOP) et au framework AspectJ. Leur utilisation etant tres similaire, 
nous allons nous concentrer uniquement sur l'AOP Alliance, dont la gestion de la 
securite est proche de celle des transactions. Dans les deux cas, il s'agit d'ajouter un 
proxy sur des Beans Spring et de modifier, par le biais de la POA, le comportement de 
certaines methodes. 

Voici un exemple de Bean gerant la securite au niveau de la couche de service a l'aide de 
1' API de l'AOP Alliance : 

<bean id="secureTodo Li stsManager" 

class=" org. acegi security. intercept. 

method.aopal 1 i ance.MethodSecurityInterceptor"> 

<property name="val idateConf igAttributes"> 

<val ue>true</val ue> 
</property> 

<property name="authenticationManager"> 

<ref bean="authenticationManager"/> 
</property> 

<property name="accessDecisionManager"> 

<ref bean="accessDeci sionManager"/> 
</property> 

<property name="runAsManager"> 

<ref bean="runAsManager"/> 
</property> 

<property name="objectDefini tionSource"> 
<val ue> 

tudu.service.TodoLi stsManager .create*=ROLE_ADMIN 
tudu.service.TodoLi stsManager .update*=ROLE_ADM IN 
tudu.service.TodoLi stsManager .del ete*=ROLE_ADMIN 
</val ue> 
</property> 
</bean> 

II est ensuite possible d'utiliser ce Bean en lieu et place du Bean todoLi stsManager. Ce 
nouveau Bean ne permet l'execution de certaines methodes qu'aux utilisateurs possedant 
lerole ROLE_ADMIN. 
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Securite des objets de domaine 

Acegi Security propose une securite au niveau des instances des objets de domaine. Nous 
avons justifie ce besoin en debut de chapitre. Si nous prenons l'exemple de Tudu Lists, 
nous avons jusqu'a present securise des URL ou des mefhodes, mais nous n'avons pas 
securise les todos eux-memes. Nous avons simplement restreint certaines fonctionnali- 
tes, par exemple, la suppression d'un todo, mais n'avons pas verifie si une personne 
supprimant un todo est bien le possesseur de ce todo. Or, seul le possesseur d'un todo 
devrait avoir le droit de l'effacer. 

Nous rencontrons ce meme type de concept dans une banque (seul le possesseur d'un 
compte peut le voir ou effectuer des retraits) ou dans un site marchant (le panier d' achat 
ne peut etre accede que par l'utilisateur qui le detient). 

Dans une application bien concue, ce type de faille de securite apparait peu souvent. II 
faudrait en effet qu'un utilisateur malveillant puisse passer en parametre l'identifiant 
d'un objet et que l'application utilise cet objet sans verifier qu'il appartient bien a l'utili- 
sateur. Dans Tudu Lists, la mefhode recherchant un todo verifie s'il appartient bien a 
l'utilisateur en cours et leve une exception si tel n'est pas le cas. II s'agit done d'un code 
specifique, contenu dans la classe TodosManagerlmpl : 

public Todo findTodo( final String todold) { 
Todo todo = todoDAO.getTodo(todoId) ; 
TodoList todoList = todo.getTodoList( ) ; 
User user = userManager.getCurrentUser( ) ; 
if ( !user.getTodoLists().contains(todoList)) { 
throw new PermissionDeniedException( 

"Permission denied to access this Todo."); 

} 

return todo; 

} 

Acegi Security propose de resoudre ce probleme de maniere globale, en ajoutant des 
listes de controle d'acces par objet. II propose pour cela de creer deux tables, 
acl_object_identity et acl_permission, qui sont chargees de stacker respectivement les 
identifiants des objets et les permissions sur ces instances. Les permissions sont en fait 
des masques de type UNIX, qui permettent de donner a des utilisateurs ou a des roles des 
droits de lecture, creation, mise a jour ou suppression par instance d'objet. 

L' implementation fournie par Acegi Security est complete et prete a l'emploi en produc- 
tion. Elle souffre cependant a notre sens d'un probleme de performance. Comme nous 
1' avons verifie avec Tudu Lists, elle impose une demultiplication des insertions et des 
suppressions en base a chaque modification d'un todo ou d'une liste (les listes pouvant 
etre partagees par de multiples utilisateurs). De plus, la verification continuelle des droits 
d'acces a un impact negatif lors de la simple lecture des donnees. 

Pour remedier a cela, Acegi Security propose un cache fonde sur Ehcache. Malheureuse- 
ment, cela pose des problemes de desynchronisation entre les objets reels et le cache, le 
cache ne prenant pas a chaud le partage d'une liste avec un nouvel utilisateur. 
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En resume 

Pour pallier la problematique des failles de securite potentielles resultant d'un manque de 
validation au niveau des instances des objets metier, Acegi Security propose une solution 
eprouvee. 

Dans la plupart des cas, il est cependant plus simple et plus performant de valider cet 
acces specifiquement dans la couche de service. 



Tudu Lists : utilisation a" Acegi Security 

Tudu Lists utilise Acegi Security pour gerer ses utilisateurs. II s'agit d'une authentifica- 
tion via un formulaire HTML simple, avec authentification automatique pour trente jours 
et des autorisations gerees au niveau des URL. 

II s'agit done d'un modele de securite simple, bien representatif d'une application Web. 

Authentification a base de formulaire HTML 

Comme la tres grande majorite des applications Web, Tudu Lists utilise une authentifica- 
tion via un formulaire HTML. Ce dernier permet de renseigner l'identifiant et le mot de 
passe de l'utilisateur et renvoie vers la page principale de l'application ou vers une page 
d'erreur en cas d'echec. 

Reprenons plus en detail le nitre d' authentification presente precedemment : 

<bean id= "authentication Processing Filter" 
cl as s=" org. acegi security . ui .webapp 

. Authenti cat ion Process ingFi 1 ter"> 

<property name=" authenti cationManager"> 
<ref bean="authenticationManager" /> 
</property> 

<property name="authenticationFailureUrl "> 

<val ue>/wel come. act i on? 1 ogin_error=true</val ue> 
</property> 

<property name="defaultTargetllrl "> 

<val ue>/secure/showTodos .action</val ue> 
</property> 

<property name="filterProcessesllrl "> 

<val ue>/j_acegi_securi ty_check</val ue> 
</property> 
</bean> 

Ce Bean permet de configurer l'URL d'erreur (authenti cationFailureUrl), ainsi que 
l'URL de succes (defaultTargetUrl) et l'URL permettant de valider 1' authentification 
(fi 1 terProcessesUrl). 

Detaillons cette version simphfiee du formulaire d' identification WEB-INF/jsp/login.jsp : 

<form action="<c:url value='/j_acegi_security_check'/>" 
method="POST"> 
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<input type="text" 

name="j_username" 

size="20" 

maxl ength="50"/> 

<input type="password" 
name="j_password" 
size="20" 
maxl ength="50"/> 

<input type="submit" val ue="<fmt:message key="login.submit"/>"/> 
<input type="reset" value="<fmt:message key="login.reset"/>"/> 



II s'agit d'un formulaire HTML classique, qui pointe vers le fi IterProcessesUrl . C'est 
tout ce qu'il suffit de coder pour obtenir un formulaire d' identification avec Acegi 
Security. 

Afin de rendre cette page plus conviviale, nous configurons la propriete authentica- 
tionFail ureUrl pour pointer vers cette meme page (Faction Struts WelcomeAction redi- 
rige vers cette JSP), en prenant en parametre login_error=true. Cela nous permet 
d'afficher un message d'erreur et de prerenseigner le champ login avec le dernier 
identifiant utilise (nous considerons que l'utilisateur s'est trompe de mot de passe, 
mais pas d' identifiant) : 

<c:if test="${not empty param.login_error}"> 
<di v cl ass="error"> 

<fmt: message key=" login. error. title "/> 
</div> 
</c:if> 

<input type="text" 

name="j_username" 

size="20" 

maxl ength="50" 
<c:if test="${not empty param.login_error}"> 

value='<^= session 



</form> 



.getAttributet Authentication Processing Filter 
. ACEGI_SECURITY_LAST_USERNAME_KEY ) %> ' 



</c:if> 



/> 



Remarquons dans cet exemple qu' Acegi Security stocke lui-meme en session le dernier 
identifiant essaye par l'utilisateur. 
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Authentification HTTP pour les services Web 

Nous avons aborde au chapitre 14, dedie aux technologies d'integration XML, l'utilisa- 
tion des services Web. Les clients SOAP etant des applications, ils s'authentifient non pas 
via un formulaire HTML mais via HTTP. Nous avons choisi ici 1' authentification HTTP 
classique, la plus simple et la plus repandue. 

Remarquons qu'il est possible, avec Acegi Security, d'avoir deux types d'authen-tifica- 
tion : une authentification par formulaire et une authentification HTTP, ce qui est totale- 
ment impossible avec la specification J2EE. 

Nous securisons specialement l'URL /vis/** : 

<bean id="filterChainProxy" 

class= "org. acegi security . uti 1 . Fi IterCha in Proxy "> 

<property name="filterInvocationDefinitionSource"> 
<val ue> 
( ... ) 

/ws/**=httpSessionContextIntegrationFi 1 ter , 
basi eProcess ingFi Iter, 
contextHol derAwareRequestFi 1 ter , 
basi cSecuri ty Enforcement Filter 

</value> 
</property> 
</bean> 

Pour cet exemple, nous avons supprime les autres parametres de securisation et avons 
ajoute des retours chariot entre les fibres afin d'ameliorer la lisibilite. 

Notons que cette URL est securisee via un fibre special d' authentification, basicProces- 
singFilter, et que la securite est appliquee via un autre fibre specifique, basicSecuri- 
tyEnf orcementFi 1 ter. 

Pour Faeces a cette URL, nous demandons un role precis dans le Bean filterlnvocation- 
Interceptor : 

<val ue> 

CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 
PATTERN_TYPE_APACHE_ANT 
/secure/admin/**=ROLE_ADMIN 
/secure/**=ROLE_USER 
/ws/**=ROLE_USER 
</val ue> 

Enfin, nous configurons les deux Beans basi eProcess! ngFi Iter et basicSecurityEnforce- 
ment-Filter : 

<bean id=" basi eProcess ingFi Iter" 

cl ass=" org. acegi security. ui .basicauth.BasicProcessingFilter"> 

<property name="authenticationManager"> 
<ref bean="authenticationManager"/> 
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</property> 

<property name="authenti cationEntryPoint"> 

<ref bean="basicAuthenticationEntryPoint"/> 
</property> 
</bean> 

<bean id="basi cAuthenti cation Entry Point" 

cl as s=" org. acegi security. ui .basicauth. 

Ba si eProcess ingFi 1 terEntryPoint"> 

<property name="realmName"> 

<value>Tudu Lists Realm</val ue> 
</property> 
</bean> 

<bean id="basi cSecurity Enforcement Fi Iter" 

cl as s=" org. acegi security. intercept. web. SecurityEnforcementFilter") 

<property name="f i 1 terSecuri ty Interceptor "> 

<ref local="filterInvocationInterceptor" /> 
</property> 

<property name="authenti cationEntryPoint"> 

<ref local="basicAuthenticationEntryPoint" /> 
</property> 
</bean> 

Un Bean de type SecurityEnforcementFilter, different de celui existant deja, est neces- 
saire, car celui-ci n'a pas la meme propriete authenticationEntryPoint. Si nous avions 
garde sur cette URL le Bean SecurityEnforcementFilter utilise dans le reste de l'applica- 
tion, il aurait, en cas d'erreur, redirige l'utilisateur vers le formulaire de login, et non vers 
1' authentification HTTP. 



Authentification automatique par cookie 

Un besoin tres couramment exprime, mais totalement ignore par la specification J2EE, 
est 1' authentification automatique pour une periode de temps donnee. L' absence de cette 
fonctionnalite frustre souvent les utilisateurs, qui tendent a ne pas revenir sur un site. 

Acegi Security fournit en standard un mecanisme stockant les donnees d'identification 
de l'utilisateur dans un cookie, ce qui permet de reauthentifier automatiquement ce 
dernier a chaque nouvelle visite. 

II s'agit d'un nitre nomme rememberMeProcessingFilter, que nous deja rencontre prece- 
demment, configure dans le Bean filterChainProxy : 

<bean id="rememberMeProcess ingFi Iter" 

cl as s=" org. acegi securi ty . ui . rememberme. 

RememberMeProcessingFil ter"> 

<property name="rememberMeServices"> 
<ref local="rememberMeServices" /> 
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</property> 
</bean> 

<bean id="rememberMeServices" 

cl ass="org.acegi security . ui . rememberme. 

TokenBasedRememberMeServices"> 



<property name="userDetai 1 s Service "> 
<ref local="userDetailsService" /> 
</property> 

<property name="tokenVal iditySeconds"> 

<value>2592000</value> 
</property> 
<property name="key"> 

<val ue>tuduRocks</val ue> 
</property> 
</bean> 

Ce filtre permet de configurer la duree de stockage du cookie, exprimee en seconde, sur 
le poste de l'utilisateur (trente jours dans notre exemple), ainsi que la cle utilisee pour le 
crypter. La methode de cryptage utilisee n'est certes pas tres avancee, surtout si la cle de 
cryptage est connue. Elle reste cependant suffisante pour un site Web classique. Si une 
personne malveillante surveille notre trafic reseau, elle aura de toute maniere deja recupere 
notre mot de passe, qui circulait en clair lors de la phase de login. 

Si nos besoins en matiere de securite sont plus eleves, nous devons considerer le passage 
en HTTPS, qui permet de crypter 1' ensemble des donnees transitant entre le serveur et les 
clients : cookies, mots de passe, mais aussi donnees metier. 

Pour etre actif, ce filtre doit s'integrer dans la phase d'authentification, en injectant le 
Bean rememberMeServices dans le filtre d'authentification : 

<bean id= "authentication Processing Filter" 
class="org.acegisecurity.ui .webapp. 

AuthenticationProcessingFi 1 ter"> 

<property name="authenticationManager"> 
<ref bean="authenticationManager" /> 
</property> 

<property name="rememberMeServices"> 
<ref bean="rememberMeServices" /> 
</property> 

( ... ) 

</bean> 

II faut en outre configurer un nouveau fournisseur d'authentification, specifique pour 
l'authentification automatique, dans le Bean authenticationManager : 

<bean id=" authenticationManager" 

class="org.acegisecurity.providers.ProviderManager"> 
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<property name="providers"> 
<11st> 

<ref local="daoAuthenticationProvider" /> 
<ref local="rememberMeAuthenticationProvider" /> 
</1ist> 
</property> 
</bean> 

<bean id="rememberMeAuthenti cat ion Provider" 

cl ass=" org. acegi security. providers. rememberme. 

RememberMeAuthenticationProvider"> 

<property name="key"> 

<val ue>tuduRocks</val ue> 
</property> 
</bean> 

Ce fournisseur d'authentification utilise la cle donnee en propriete pour decrypter le 
login et le mot de passe stockes dans le cookie de l'utilisateur. 



Implementation d'un DAO specif ique d'authentification 

Dans Tudu Lists, un utilisateur est avant tout un « possesseur de todos ». Nous voulons 
que cet objet metier soit utilise a la fois par 1' application et par Acegi Security. Nous lui 
ajoutons done un mot de passe et des roles. De plus, les objets de Tudu Lists etant sauve- 
gardes en base de donnees grace a Hibernate, nous voulons un comportement consistant 
entre l'application et Acegi Security. Si nous n'avions pas un objet utilisateur unique, les 
caches utilises par Hibernate et Acegi Security pourraient etre desynchronises. 

Pour cette raison, nous sommes contraints de creer notre propre DAO, integrant Acegi 
Security avec la couche de domaine de Tudu Lists, fondee sur Hibernate. Notre objectif 
final est d'utiliser ce DAO en lieu et place du DAO fourni par Acegi Security, que nous 
avons deja rencontre pour l'authentirication via la base de donnees : 

<bean id="authenti cat ion Provider" 

cl ass=" org. acegi security.providers.dao.DaoAuthenticationProvider"> 

<property name="userDetai 1 sService"> 
<ref local="userDetailsService" /> 
</property> 
</bean> 

<bean id="userDetailsService" 

cl as s=" tudu. security. User DetailsServicelmpl "> 

<property name="userManager"> 
<ref bean="userManager" /> 
</property> 
</bean> 
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Pour que cette integration fonctionne, nous codons le Bean tudu. security. UserDe- 
tai 1 sServi celmpl , qui implemente l'interface org. acegisecurity.userdetails. User- 
Detail sServi ce. En voici la methode principale, qui permet de renseigner un objet 
d'Acegi Security a partir de donnees provenant de la couche de persistance de Tudu 
Lists : 

public UserDetails loadUserByUsernametString login) 
throws UsernameNotFoundException, DataAccessException { 



login = 1 ogin .toLowerCase( ) ; 

User user = userManager.findUser(login); 



Set<Role> roles = user .getRol est ) ; 
GrantedAuthority[] arrayAuths = 
new GrantedAuthori ty[rol es.sizeO] ; 

int index = 0; 
for (Role role : roles) { 
GrantedAuthoritylmpl authority = 
new GrantedAuthoritylmpl (role.getRoleO); 

arrayAuths[index++] = authority; 

} 

org. acegisecurity.userdetails. User acegiUser = 
new org. acegisecurity.userdeta ils. User ( 
login, user.getPasswordt ) , user. isEnabl ed( ) , true, true, 
true, arrayAuths); 



return acegiUser; 

} 

Cette methode renseigne un objet User et des objets GrantedAuthori ty, qui sont propres a 
Acegi Security. Le premier stocke des donnees utilisateur (login, mot de passe), tandis 
que les autres stockent ses autorisations. 

Cet exemple montre qu'il est relativement aise de connecter Acegi Security a un systeme 
proprietaire specifique. Nous obtenons de la sorte un systeme unifie, au lieu d' avoir deux 
systemes dont les caches seraient probablement desynchronises de temps a autre. 



Recherche de I' utilisateur en cours 

Une fonctionnalite souvent utile est la recherche de l'utilisateur en cours, un sujet 
egalement mal gere par la specification J2EE, qui ne propose pour cela qu'une methode 
getRemoteUser( ) associee a l'objet HttpServletRequest. Que faire si nous recherchons l'utili- 
sateur ailleurs que dans une servlet ? 
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Acegi Security stocke l'utilisateur dans une variable associee au til d'execution en cours 
et peut done le retrouver a n'importe quel endroit de 1' application. II suffit d'ajouter la 
methode suivante au Bean userManager : 

public User getCurrentUser( ) { 
SecurityContext securityContext = 
SecurityContextHolder.getContext( ) ; 

org. acegisecurity.userdetails. User acegiUser = 
(org. acegi security . userdetai 1 s .User) 
securi ty Context .getAuthenti cation ( ) .getPrincipal ( ) ; 

tudu. domain. model .User user = 
this.findUser (acegi User. getUsername( )) ; 

return user; 

} 

En injectant ce Bean et en appelant la methode ci-dessus, nous pouvons retrouver l'utili- 
sateur en cours, et ce, quelle que soit la couche de l'application dans laquelle nous nous 
trouvons. 



Gestion des autorisations dans les JSP 

Acegi Security s'integre de deux manieres au sein des JSP : via une bibliotheque de tags 
specifique ou via la securite J2EE standard. Nous choisissons d'utiliser la securite J2EE 
standard a la fois pour minimiser les dependances a Acegi Security et parce que l'API 
standard est deja largement connue des developpeurs. 

Pour integrer cette securite standard dans les JSP, nous utilisons le filtre context Holde- 
rAwareRequestFilter dans la configuration du Bean filterChainProxy, que nous avons 
rencontre. 

Ce filtre se configure tres simplement : 

<bean id="contextHolderAwareRequest Filter" 
cl ass=" org. acegi security .wrapper. 

SecurityContextHolderAwareRequestFi 1 ter" /> 

Son role est d'enrober la requete HTTP afin de surcharger les methodes getRemoteUser et 
isUserlnRole, integrant ainsi de maniere transparente Acegi Security avec les methodes 
standards J2EE. 

Suite au passage de ce filtre, nous pouvons utiliser dans l'ensemble de l'application la 
securite standard, notamment dans la configuration de Struts (afin de limiter 1' execution 
de certaines Actions en fonction du role de l'utilisateur) et a l'interieur des servlets. 
Cependant, le meilleur parti que nous pouvons tirer de ce filtre est de l'utiliser au niveau 
des JSP, afin de n'afficher que certaines portions de pages en fonction de l'utilisateur. 
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Nous retrouvons cette utilisation dans la page WEB-INF/jspf7header.jsp, qui affiche des 
menus en fonction du role de l'utilisateur ainsi que son identifiant s'il est authentifie. En 
voici une version simplifiee : 

<% 

if (request. isUserInRole("ROLE_USER")) { 
%> 

<menu:useMenuDispl ayer name="TabbedMenu" 

bundle=" org. apache. struts. action. MESSAGE "> 

<menu:di spl ayMenu name="Todos"/> 
<% 

if ( request . isUserlnRol e( "ROLE_ADMIN" ) ) { 

%> 

<menu:displ ayMenu name="Administration"/> 
<% 
) 

%> 

<menu:di spl ayMenu name=" Logout "/> 
</menu: useMenuDi spl ayer> 
<% 
} 

%> 

Nous aurions pu egalement utiliser la bibliotheque de tags 1 ogi c de Struts avec un resultat 
similaire, sans utiliser de code Java : 

<1 ogi c: present rol e="ROLE_USER"> 

Ce texte s' affiche si l'utilisateur possede le role demande. 
</logic:present> 



Utilisation d'un cache 

Au cours de ce chapitre, nous avons vu comment securiser une application Web sans trap 
nous soucier de la performance. Pour effectuer chaque validation, Acegi Security doit 
appeler des systemes externes, notamment des bases de donnees et des annuaires LDAP 
dans nos exemples. Ces appels, multiplies par le nombre de requetes, sont malheureusement 
cofiteux en performances. 

Pour remedier a ce probleme, nous utilisons un cache, d'une maniere tres similaire a 
celle que nous avons rencontree au chapitre 11, consacre a la persistance. Acegi Security 
utilise d'ailleurs le meme produit que celui introduit pour Hibernate, Ehcache. Cela offre 
un appreciable gain de temps en terme d' installation et de configuration. 

Ce cache permet d'eviter d' appeler systematiquement le DAO d'authentification. Nous le 
configurons au sein du daoauthenticationProvider, dans la propriete userCache : 

<bean id="daoAuthenti cat ion Provider" 

cl as s=" org. acegi security .providers .dao. 

DaoAuthenticationProvider"> 
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<property name="userDetai 1 sService"> 
<ref local="userDetailsService" /> 
</property> 

<property name="userCache"> 
<ref local="userCache" /> 
</property> 
</bean> 

userCache represente un Bean specifique, configure de la maniere suivante : 

<bean id="userCache" 

class="org. acegi security. providers.dao. cache. 

EhCacheBasedUserCache"> 

<property name="cache"> 
<bean cl as s= "org. springframework. cache. ehcache. 

EhCacheFactoryBean"> 

<property name="cacheManager"> 
<bean cl ass=" org. springframework. cache. ehcache. 

EhCacheManagerFactoryBean" /> 

</property> 

<property name="cacheName"> 

<val ue>AcegiUserCache</val ue> 
</property> 
</bean> 
</property> 
</bean> 

Les donnees d'authentification retournees par le DAO sont ainsi stockees dans un cache 
Ehcache, qui se configure dans le fichier ehcache.xml, au cote de la configuration 
d' Hibernate : 

<cache name="Acegi UserCache" 

maxEl ementsInMemory="5000" 
eternal="false" 
overf 1 owToDisk="true" 
timeToIdl eSeconds="300"/> 

Dans cet exemple, les donnees d'authentification d'un utilisateur sont conservees 
pendant cinq minutes apres le dernier acces. 

Conclusion 

La securite est une problematique critique pour toute application Web. Malheureuse- 
ment, la specification J2EE est particulierement lacunaire a cet egard. De nombreux 
projets sont contraints de developper leur propre modele de securite, alors me me qu'il 
s'agit d'une preoccupation recurrente, qui devrait beneficier de solutions generiques. 

De plus, comme nous l'avons montre dans ce chapitre, la securite est un domaine 
complexe, qu'il ne faut pas traiter a la legere. 
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Acegi Security propose un modele de securite eprouve, stable et performant, a meme de 
repondre a 1' ensemble des attentes : securisation des URL, des methodes et des instances 
d'objets, fourniture de nombreux filtres, permettant l'authentification par formulaire, 
authentification automatique par cookie, etc. 

II s'agit cependant d'un framework difficile a maitriser et a mettre en place. Dans ce 
chapitre, nous l'avons volontairement utilise dans une etude de cas simple, afin de servir 
de base a des configurations plus ambitieuses. 

Le framework Acegi Security etant tres peu intrusif, sa configuration est independante de 
celle des autres Beans Spring. C'est la son principal atout. La securite est en effet une 
notion transversale, qui ne doit pas avoir d' impact sur 1' application en elle-meme. 
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Outre son conteneur leger, son support de la POA et 1' integration de frameworks tiers, 
Spring offre un ensemble d' outils facilitant les tests d' applications ainsi que leur 
supervision. Ces outils sont tres utiles pour garantir la qualite de service des applications. 

Le chapitre 16 decrit la technologie JMX, qui offre un cadre generique pour superviser 
les applications. Nous detaillons le support de cette technologie par Spring et 
montrons comment il facilite sa mise en oeuvre en impactant au minimum le code des 
applications Java/J2EE. 

Le chapitre 17 aborde les tests unitaires et d' integration. Spring offre un support effi- 
cace des tests fondes sur JUnit afin de faciliter leur mise en oeuvre pour verifier le bon 
fonctionnement des differents composants d'une application. 
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Supervision avec JMX 



La supervision offre un cadre normalise et homogene pour visualiser des informations 
relatives a une application et d'interagir avec son parametrage lors de son execution. Ces 
informations peuvent etre visualisees a la demande de la console de supervision ou etre 
dispatchers par 1' application elle-meme. Les enjeux de la supervision sont aussi bien 
1' augmentation de la disponibilite des applications et de la reactivite face aux problemes 
d' execution que la facilitation du control e des systemes d' information. 

Java s'est tres vite oriente vers la supervision par le biais de la technologie JMX (Java 
Management extensions). L'objectif de JMX est de definir une architecture ainsi qu'un 
ensemble d'interfaces de programmation standards afin de superviser grace a ce langage 
des reseaux, des services et des equipements dont les composants peuvent etre ecrits dans 
divers langages. 

Nous entendons par supervision le fait d'acceder a des informations sur l'etat de compo- 
sants a un moment donne de l'execution d'une application, ce qui est particulierement 
interessant pour determiner les causes de dysfonctionnements d'une application. 

Le succes de JMX est tel dans le monde Java/J2EE que cette technologie est desormais 
integree aux serveurs d' applications J2EE ainsi qu' a certains frameworks. Cette mise en 
oeuvre donne acces a des informations concernant les ressources utilisees et permet 
d'effectuer des operations d' administration durant l'execution des applications. 
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Les specifications JMX 

Cette section presente 1' ensemble des specifications relatives a JMX et donne un apercu 
de son architecture generale ainsi que des concepts mis en oeuvre. 

La fin de la section traite des differentes implementations de JMX ainsi que des consoles 
JMX disponibles. 

La technologie JMX comporte plusieurs specifications differentes, notamment les deux 
suivantes, qui en decrivent les fondations : 

• JSR 3, en version 1.2 actuellement, qui concerne les concepts et l'architecture de JMX. 

• JSR 160, qui etend la precedente et standardise la maniere d'acceder aux agents 
JMX depuis les applications de supervision compatibles JMX, englobant les aspects 
d'interoperabilite, de transparence et de securite des acces. 

Une autre specification, la JSR 255, prend le relais des precedentes arm de decrire la 
version 2.0 de JMX, qui sera integree a la version 6.0 de Java. Le present ouvrage ne traitant 
pas de cette version de Java, nous ne detaillons pas cette specification. 

Lobjectif des specifications JMX est de decrire la maniere de recuperer des informations 
concernant des ressources applicatives, d'interagir avec ces dernieres et de declencher 
certaines operations. Ces ressources peuvent correspondre a des composants techniques, 
tels que des pools de connexions, mais egalement des composants d'une application ou 
d'un framework. 

JMX fournit un cadre robuste, qui permet de specifier finement les proprietes et actions 
accessibles des composants. La technologie propose egalement un mecanisme pour notifier 
les applications de supervision suite a des evenements. 

Architecture de JMX 

JMX a pour objet de standardiser la structuration des composants supervisables tout en 
les rendant accessibles aux outils de supervision. 

La specification met en oeuvre une architecture a trois niveaux, comme illustre a la 
figure 16.1 : 

• Le niveau le plus proche des ressources correspond a V instrumentation, dont l'objectif est 
de fournir une ressource supervisable. La specification JMX offre divers cadres techniques 
a cet effet, dont certains ont un impact sur les ressources. 

• La couche intermediate entre ces ressources et les outils de supervision gere les 
differentes ressources supervisables et est nommee agents. Les entites de cette 
couche permettent notamment d'associer un nom a une ressource supervisable ainsi 
que des observateurs. 

• Le niveau services distribues specifie 1' acces aux ressources par les outils ou applications 
de supervision par le biais de differents protocoles ou connecteurs. 
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Figure 16.1 

Architecture de JMX 



Afin de decrire les differents MBeans JMX, nous allons commencer par introduire un 
exemple issu de Tudu Lists. L'objectif est de superviser le composant applicatif d'identifiant 
datasource afin de visualiser et eventuellement de modifier ses proprietes. 

Ce composant est configure dans le fichier applicationContext-hibernate.xml localise 
dans le repertoire WEB-INF : 

<bean id="dataSource" class="org.springframework 

. jdbc. datasource. DriverManagerDataSource"> 
<property name="dri verCl ass Name" 

val ue="${ jdbc.dri verCl assName} "/> 
<property name="url" val ue="$(jdbc.url }"/> 
<property name="username" value="${jdbc.username}"/> 
<property name="password" value="$(jdbc.password}"/> 
</bean> 

Comme le montre le code ci-dessus, le composant possede les proprietes suivantes : 

• driverClassName, qui specifie la classe du driver JDBC utilisee. 

• url , qui definit l'adresse JDBC de la base de donnees utilisee. 

• username et password, qui specifient respectivement l'identifiant et le mot de passe de 
l'utilisateur. 

Les valeurs de ces proprietes sont definies dans le fichier hibernate.properties localise 
dans le repertoire WEB-INF : 

(...) 

jdbc.driverClassName=com.inysql .jdbc. Driver 

jdbc. url =jdbc:mysql : //I ocal host :3306/tudu 

jdbc.username=root 

jdbc.password= 

(...) 
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Le niveau instrumentation 

Le MBean (Managed Bean) est l'entite de base de JMX. II definit un cadre de conception 
afin qu'un serveur de supervision compatible JMX puisse determiner ou positionner la 
valeur d'une propriete ainsi qu'appeler une methode d'un composant applicatif. 

JMX decrit quatre types de MBeans, qui repondent a des regies de mise en ceuvre 
variees, adaptees aux divers besoins des applications en terme de fonctionnalites et de 
complexite. Ces differentes regies doivent etre strictement suivies afin que les MBeans 
soient compatibles JMX. Remarquons que, dans le cas contraire, ils sont considered 
comme incompatibles. Dans ce cas, une exception de type NotCompliantMBeanException 
est levee lors de leur enregistrement. 

La validite de ces regies est verifiee par le serveur de MBeans au moment de 1' enregistrement 
en utilisant les mecanismes d' introspection de Java. 

Le tableau 16.1 recapitule les differents types de MBeans specifies par JMX. Nous les 
decrivons plus en detail a la section suivante. 



Tableau 16.1. MBeans specifies par JMX 


Type 


Description 


StandardMBean 


Correspond au type de MBean le plus simple. II s'appuie sur une interface utilisateur afin de 
determiner les metadonnees a exposer dans JMX. 


DynamicMBean 


Bend le type de MBean precedent afin de rendre dynamique la determination des metadonnees. 
II s'appuie sur une interface definie par la specification JMX. 


ModelMBean 


Permet de specifier les metadonnees a exposer dans JMX par I'intermediaire d'interfaces et de 
classes de JMX sans impacter le composant. 


OpenMBean 


Bend le type de MBean precedent afin d'adresser des utilisations avancees de JMX. 



Les differents types de MBeans 

JMX offre diverses possibilites pour mettre en ceuvre des MBeans offrant differentes 
caracteristiques et ayant plus ou moins d' impact sur 1' architecture et les composants eux- 
memes. 

Le premier type de MBean, StandardMBean, se distingue par sa simplicite. Seule la mise en 
ceuvre d'une interface specifique est necessaire pour decrire les proprietes et methodes 
accessibles par JMX. Le Bean a superviser doit imperativement implementer cette inter- 
face. De ce fait, il se trouve lie explicitement a la specification, sauf a recourir a la POA, 
qui permet d'ajouter cette interface a la classe de maniere transparente. 

L'interface doit respecter certaines conventions decrites par la specification JMX. De ce 
fait, elle doit etre codee pour un composant specifique, et son nom doit etre suffixe par 
MBean. Au travers de cette interface, ce dernier definit les proprietes et methodes exposees 
dans JMX. Remarquons que ces proprietes sont mises en ceuvre grace a des accesseurs et 
des modificateurs. Si l'accesseur est omis, la propriete est en lecture seule. Inversement, 
si le modificateur est omis, la propriete est uniquement disponible en ecriture. 
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Comme la classe DriverManagerDataSource est non pas une classe de l'application mais 
une classe du support JDBC de Spring, nous ne pouvons pas la modifier. Nous devons 
done creer une sous-classe afin de lui ajouter des methodes et d' implementer 1' interface 
JMX. 

Nous nommons cette sous-classe JmxDriverManagerDataSource et la configurons dans le 
fichier de configuration applicationContext-hibernate.xml de la maniere suivante : 

<bean id="dataSource" cl ass="tudu. jmx. JmxDri verManagerDataSource"> 

<property name="dri verCl ass Name" 

val ue="${ jdbc.dri verCl assName} "/> 

<property name="url" val ue="$(jdbc.url }"/> 

<property name="username" value="$(jdbc.username}"/> 

<property name="password" value="${jdbc.password}"/> 
</bean> 

Le code suivant decrit 1' interface que le composant doit implementer pour definir les 
proprietes et methodes exposees dans JMX : 

public interface JmxDriverManagerDataSourceMBean { 
String getDri verCl assName( ) ; 
String getUrl ( ) ; 

String getUsernamet ) ; 

void setUsername(String username); 

String getPasswordt ) ; 

void setPassword(String password); 

void resetO; 

} 

Le composant doit implementer cette interface pour etre utilisable par JMX, comme dans 
le code suivant : 

public class JmxDriverManagerDataSource 

extends DriverManagerDataSource 

implements JmxDriverManagerDataSourceMBean { 

public void resetO { (...) ) 

} 

Notons que la propriete username est en lecture -ecriture, tandis que la propriete dri ver- 
Cl assName est en lecture seule. 

Ce type de MBean est contraignant, puisqu'il impose de se Her aux conventions JMX, et 
n'est done pas transparent pour l'application. 

Le MBean DynamicMBean utilise le meme principe que precedemment mais permet en 
outre de decrire de maniere dynamique les proprietes et methodes exposees dans JMX 
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par le biais de l'interface DynamicMBean. Celle-ci est localisee dans le package javax. mana- 
gement et decrite de la facon suivante : 

public interface DynamicMBean { 

public Object getAttribute(String attribute) 

throws Attn' buteNot Found Except ion, 

MBean Except ion, Reflection Exception; 
public void setAttribute(Attribute attribute) 

throws Attn' buteNot Found Except ion, 

Inval idAttributeVal ueException, 

MBean Except ion, Reflection Exception; 
public AttributeList getAttributes(String[] attributes); 
public AttributeList setAttributes(Attributel_ist attributes); 
public Object invoke( String actionName, 

Object params[], String signature[]) 

throws MBeanException, ReflectionException; 
public MBeanlnfo getMBeanlnfot ) ; 

} 

Cette interface utilise la classe MBeanlnfo du package javax. management, qui permet de 
decrire les metadonnees d'un MBean. Notons egalement dans le code ci-dessus l'utilisa- 
tion de la classe AttributeList du meme package afin d'etendre la classe ArrayList et 
d'empecher l'ajout d'instances autres que de type Attribute. Cette derniere permet de 
stacker une cle ainsi que sa valeur associee. 

Le composant doit implementer cette interface pour renvoyer les valeurs pour des noms 
de proprietes ainsi que les metadonnees du MBean. 

Le code suivant illustre la mise en ceuvre des methodes getAttribute et invoke dans le 
composant precedent afin de le convertir en Dynami cMBean : 

public class JmxDriverManagerDataSource 

extends DriverManagerDataSource 
implements DynamicMBean { 

public void resetO { (...) } 

public Object getAttribute(String attribute) 

throws AttributeNotFoundException, 
MBeanException, ReflectionException { 
if( "driverClassName".equals(attribute) ) { 

return getDriverClassNameO; 
} else if( "urT'.equals(attribute) ) { 

return getUrl ( ) ; 
} else if( "username".equals(attribute) ) { 

return getUsername( ) ; 
} else if( "password". equals(attribute) ) { 

return getPassword( ) ; 
} else { 
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throw new AttributeNotFoundException( 
"L'attribut avec le nom "+attribute+ 
" n'existe pas pour le MBean"); 

} 

} 

public Object invoke(String actionName, 

Object params[]. String signature[]) 
throws MBeanException, ReflectionException; 
if( "reset". equal s(actionName) ) { 
reset( ) ; 
return nul 1 ; 
} else { 

throw OperationsExceptionC 

"L'action avec le nom "+actionName+ 
"n'existe pas pour le MBean"); 

} 

} 

} 

Comme pour le premier type, l'utilisation de DynamicMBean est contraignante. Elle impose 
en effet de se lier aux API JMX, ce qui n'est pas transparent pour l'application (a moins 
d'utiliser la POA). 

Le type Model MBean ouvre une perspective interessante pour creer un MBean sans impact 
sur le composant lui-meme en jouant un role de proxy II permet de decrire les informa- 
tions concernant les proprietes et methodes supervisees par 1' intermediate de l'interface 
Model MBean de JMX, localisee dans le package javax. management, dont le code est le 
suivant : 

public interface ModelMBean extends DynamicMBean, 

Persi stentMBean , ModelMBeanNotificationBroadcaster { 
public void setModelMBeanInfo(ModelMBeanInfo inModelMBeanlnfo) 
throws MBeanException, RuntimeOperationsException; 
public void setManagedResource(Object mr, String ntr_type) 

throws MBeanException, RuntimeOperationsException. 
InstanceNotFoundException , 
Inval idTargetObjectTypeException ; 

} 

Le developpement de ce MBean comporte les trois etapes suivantes : 

1. Instanciation du MBean par le biais de l'unique implementation RequiredModel MBean 
du package javax. management. modelmbean, fournie par la specification JMX. 

2. Definition des metadonnees du MBean par le biais de la classe Model MBean Info du 
package javax. management, comme dans le code suivant : 

//Creation de la description des attributs, des operations, 
//des constructeurs et des notifications du MBean 
Model MBeanAttributeInfo[] attributes=new Model MBeanAttributeInfo[l] ; 
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Descriptor champlDesc = new DescriptorSupport( ) ; 
champlDesc.setFiel d( "name" , "username" ) ; 
champlDesc. set Fi el d( "descriptorType" , "attribute" ) ; 
champlDesc.setFiel d( "displ ay Name" , "Username" ) ; 
champlDesc.setFiel d( "getMethod" , "getUsername" ) ; 
champlDesc. set Fi el d( "setMethod" , "setUsername" ) ; 
champlDesc.setFiel d( "currencyTimeLi mi t" , "20" ) ; 

attributes[0]=new Model MBeanAttributeInfo( 

"username" , " java .1 ang. String" . 
"Description de Username. ", true, 
true, false. champlDesc) ; 

(...) 

Model MBeanOperati on Info[] operations 

=new ModelMBeanOperationInfo[0] ; 
Model MBeanConstructorInfo[] contructors 

=new ModelMBeanConstructorInfo[0] ; 
Model MBeanNotificationInfo[] notifications 

=new ModelMBeanNotificationlnfo [0]; 

//Creation de la description globale du MBean 

Descriptor descriptor=new DescriptorSupport( new String[] 

{ "name=JmxDriverManagerDataSource" , "descriptorType=mbean" , 

"displ ayName=JmxDri verManagerDataSource" , "1 og=T" , 

"1 ogf i 1 e=jmx.log" , "currencyTimeLimit=5") ) ; 

// Creation du ModelMBeanlnfo pour 1 'ensemble du MBean 

String cl a ssName="JmxDri verManagerDataSource" ; 

String description="Description du MBean sur MonComposant. " ; 

ModelMBeanlnfo info=new ModelMBeanInfoSupport( 

class Name, description, attributes, 
constructors .operations .notifications) ; 

dMBeanlnfo.setMBeanDescri ptor(mmbDesc) ; 

3. Positionnement des metadonnees et rattachement du Bean au MBean lui-meme, 
comme dans le code suivant : 

JmxDri verManagerDataSource jmxDataSource = createDataSource( ) ; 

ModelMBean mbean = new Requi redModelMBeant ) ; 
mbean .setModel MBean Info (mbean Info) ; 

mbean . setManagedResource( jmxDataSource, "ObjectReference" ) ; 

Notons qu'un autre type de MBean, OpenMBean, est reserve aux usages avances de JMX et 
n'est pas detaille dans ce chapitre. 
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Le niveau agent 

Ce niveau specifie les differents composants de 1' infrastructure de JMX qui permettent 
de gerer les MBeans. Appeles agents ou serveurs JMX, ces composants offrent la possi- 
bility d'enregistrer ou de desenregistrer les MBeans. 

Un MBean est identifie de maniere unique par un identifiant specifie au moment de son 
enregistrement dans le serveur de MBeans. Designe par le terme ObjectName, cet identifiant 
se presente sous la forme suivante : 

domai n -name: key l=val uel[ , key2=val ue2 keyN=val ueN] 

L' element domain-name symbolise le domaine du MBean. II est suivi d'une liste de cles- 
valeurs, qui permet de l'identifier, avec, par exemple, une cle ayant pour valeur name. 

JMX fournit la classe ObjectName pour specifier cet identifiant. 
Recuperation du serveur de MBeans 

Un serveur de MBeans peut etre embarque dans l'application ou fourni par l'infras- 
tructure dans laquelle fonctionne l'application, comme, par exemple, un serveur 
d' applications. 

Dans le premier cas, il est explicitement cree au moyen de la classe JMX MBeanServer- 
Factory et de sa methode createMBeanServer. Le code suivant en donne un exemple d'utili- 
sation : 

MBeanServer server = MBeanServerFactory .createMBeanServert ) ; 

Dans le cas d'un serveur JMX fourni par 1' infrastructure, une recherche du serveur 
s'impose. La classe MBeanServerFactory offre pour cela la methode findMBeanServer, qui 
prend en parametre l'identifiant de 1' agent, c'est-a-dire du serveur. Ce parametre peut 
prendre la valeur nul 1 . Dans ce cas, tous les serveurs presents sont detectes. 

Le code ci-dessous en donne un exemple d'utilisation : 

List servers = MBeanServerFactory .findMBeanServer(agentld) ; 

Enregistrement de MBeans 

A partir des notions que nous venons de voir, nous pouvons deduire la facilite avec 
laquelle il est possible d'enregistrer un MBean. Cela s'effectue en utilisant le nom de la 
classe a enregistrer ou une instance de celle-ci. L'interface MBeanServer, materialisant le 
contrat du serveur JMX, fournit pour cela les methodes createMBean et registerMBean. 

Le code suivant illustre la maniere d'enregistrer un MBean avec la methode registerM- 
Bean : 

MBeanServer=getMBeanServer( ) ; 

ObjectName objName=new ObjectName( "MonDomain :Name=Test" ) ; 

Test test=new Test( ) ; 

server . regis terMBean( test , objName) ; 
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Le suivant illustre la facon de creer un MBean grace a la methode createMBean : 
MBeanServer=getMBeanServer( ) ; 

ObjectName objName=new ObjectName("MonDomain:Naine=Test"); 
server. createMBeanC'package. Test" , objName) ; 

De meme, cette interface fournit la methode unregisterMBean pour desenregistrer un 
MBean, comme dans le code suivant : 

MBeanServer=getMBeanServer( ) ; 

ObjectName objName=new ObjectName("MonDomain:Naine=Test"); 
server. unregi sterMBean( objName) ; 

Le niveau services distribues 

Ce niveau specifie la facon dont les applications clientes de supervision peuvent se 
connecter au serve ur JMX depuis l'exterieur. 

La specification decrit les deux approches suivantes pour cela : 

• Approche par adaptateur de protocole. Reduit l'impact de JMX sur les applications 
clientes en donnant acces aux composants JMX du serveur par le biais d'un protocole 
donne. Cette approche a l'avantage de se fonder sur des protocoles existants. La 
communaute J2EE possede notamment des projets d'adaptateurs pour les protocoles 
SNMP, HTTP et CORBA. 

• Approche par connecteur. Contrairement aux adaptateurs, les connecteurs ont un 
impact sur l'application cliente puisqu'ils sont composes d'une partie cliente et d'une 
partie serveur, ces entites etant standardises par le biais de la JSR 160. 

Le code suivant illustre l'utilisation d'un connecteur avec les API JMX au niveau du 
serveur JMX arm d'autoriser son acces : 

//Recuperation du serveur JMX 
MbeanServer server= getMBeanServer( ) ; 

//Creation de l'URL d'acces au connecteur 
JMXServiceLIRL url=new JMXServiceURLCserviceUrl ) ; 

//Creation de 1 'environnement 

Map envi ronment=createEnvi ronmentt ) ; 

//Creation du connecteur serveur 
JMXConnectorServer connectorServer 

JMXConnecto rServer Facto ry.newJMXConnectorServer( 

url , environment, server); 

//Demarrage du connecteur 
connectorServer. startt ) ; 

(...) 
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/Arret du connecteur 

connectorServer.stopt ) ; 

Une fois la partie serveur du connecteur realisee, l'application cliente met en ceuvre un 
connecteur client, comme dans le code suivant : 

//Creation de 1'URL du connecteur a acceder 
JMXServiceURL url=new JMXServi cellRL(serviceUrl ) ; 

//Creation de 1 'environnement 

Map envi ronment=createEnvi roninent( ) ; 

//Creation du connecteur client 

JMXConnector connector=JMXConnector Factory .connect ( 

url , this. environment) ; 

//Recuperation d'un connecteur au serveur JMX 
MbeanServerConnection connect ion= 

connector. getMBeanServerConnectiont ) ; 

Les notifications JMX 

La specification JMX standardise un mecanisme robuste et complet permettant aux 
composants enregistres ou aux agents JMX d'emettre des notifications vers les applications 
de supervision. 

Les mecanismes de notification s'appuient sur les deux interfaces JMX decrivant l'obser- 
vation ainsi que la facon de les associer ou les dissocier d'un MBean. 

Linterface NotificationListener du package javax. management represente un observateur 
JMX qui peut etre notifie par divers evenements. Les observateurs JMX doivent imple- 
menter cette interface, decrite dans le code suivant : 

public interface NotificationListener { 

void handleNotification(Notification notification, 

Object handback) ; 

} 

Elle definit ensuite une fonction de rappel, qui est invoquee lorsqu'un de ces MBeans 
observes emet une notification. Le second parametre de la methode handleNotifi cation 
correspond a des informations globales, specifiees au moment de l'enregistrement des 
observateurs. 

Pour finir, l'interface Notif icationBroadcaster du package javax. management permet aux 
MBeans d' associer et de desassocier des observateurs par le biais de methodes de cette 
interface appelees par le serveur de MBeans. 

Le code suivant decrit cette interface : 

public interface NotificationBroadcaster { 

void addNotificationl_istener( NotificationListener 1 istener, 
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NotificationFilter filter, Object handback); 
MBeanNoti f 1 cation Info[] get Not if i cationInfo( ) ; 
void removeNotif i cation Li stenert 

NotificationListener listener) ; 

} 

La figure 16.2 illustre 1' association et la desassociation des observateurs sur un MBean 
ainsi que la notification. 



Figure 16.2 
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Les MBeans de types simple et dynamique doivent necessairement implementer l'inter- 
face NotificationBroadcaster pour utiliser les mecanismes de notification. La specifi- 
cation JMX fournit pour cela 1' implementation NotificationBroadcasterSupport de cette 
interface dans le package javax. management, que ces types de MBeans peuvent etendre 
pour beneficier directement de ces mecanismes. 

Les MBeans de type modele fonctionnent differernment pour les notifications. Limplemen- 
tation RequiredModel MBean de l'interface Model MBean etend indirectement NotificationBroad- 
caster par le biais de l'interface Model MBeanNoti f i cati onBroadcaster. Cela permet a ce type de 
MBeans de beneficier automatiquement des mecanismes de notification. 

Enregistrement 

Une fois les MBeans prets a utiliser les mecanismes de notification et les observateurs 
implemented, l'application doit les associer les uns aux autres par l'intermediaire du 
serveur de MBeans. 

Le serveur fournit les methodes addNotificationListener et removeNotificationListener 
dans son interface MBeanServer dans le but d'associer ou de desassocier un observateur, 
dont les signatures sont decrites dans le code ci-dessous : 

public interface MBeanServer extends MBeanServerConnection ( 
(...) 

void addNotificationListener(ObjectName name, 
NotificationListener 1 istener, 
NotificationFilter filter, Object handback); 
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void addNotificationListenert 



ObjectName name, ObjectName listener, 
NotificationFilter filter, Object handback); 



void removeNotificationl_istener( 



ObjectName name, ObjectName listener); 



void removeNotificationl_istener( 



ObjectName name, ObjectName listener, 
NotificationFilter filter, Object handback); 



(...) 



L' association et la desassociation peuvent etre realisees en utilisant 1' instance ou le nom 
JMX de l'observateur. Dans le premier cas, l'observateur est ajoute automatiquement 
dans JMX. 

Les methodes precedentes permettent de specifier egalement les parametres suivants : 

• Un filtre de type NotificationFilter offrant la possibilite de filtrer les notifications 
envoyees a l'observateur. La specification JMX fournit 1' implementation Notification- 
FilterSupport pour cette interface. 

• Un objet handback permettant de specifier des informations generates envoyees a 
l'observateur en meme temps que les notifications. 

Le code suivant illustre la facon d'utiliser le serveur de MBeans afin d'associer ou de 
desassocier un observateur a un MBean : 

//Recuperation du serveur utilise 
MBeanServer server=getMBeanServer( ) ; 

//Creation du MBean 

ModelMBean modelMBean=createModelMBean( ) ; 
ObjectName objectName=getObjectName( ) ; 

//Enregi strement du MBean dans le serveur 
server. registerMBean( model MBean, ObjectName) ; 

//Creation de l'observateur 

Notification Listener 1 istener=createNotif i cation Listener ( ) ; 

//Association de l'observateur pour le MBean 

server. addNotificationListenert ObjectName, 1 istener.nul 1 ,null ) ; 



(...) 



//Desenregi strement du MBean dans le serveur 
server .unregisterMBeant ObjectName) ; 



//Desassociation de l'observateur pour le MBean 
server. removeNotifi cation Li stener(objectName,l istener) ; 
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Implementations de JMX 

Cette section decrit les implementations JMX les plus courantes ainsi que les consoles de 
supervision compatibles JMX. 

Implementations serveur 

Contrairement aux versions precedentes, la version 5 de la machine virtuelle Java inclut 
en natif un serveur JMX, qui permet de superviser aussi bien ses constituants que les 
composants des applications. 

Pour l'activer, le parametre com. sun. management. jmxremote doit etre specifie dans la 
ligne de commande de lancement de la machine virtuelle, comme l'illustre le code 
suivant : 

> java -Dcom. sun. management. jmxremote -classpath (...) (...) 

Le projet MX4J, accessible a l'adresse http://mx4j.sourceforge.net/, propose une implementa- 
tion Open Source robuste de JMX. La specification du parametre j a vax. management. bui 1 - 
der. initial dans la ligne de commande de lancement de la machine virtuelle permet de 
l'utiliser, comme dans le code suivant : 

> java -Djavax. management. builder. initial 

=mx4j . server. MX4JMBeanServerBui 1 der -classpath (...) (...) 

Les serveurs d' applications J2EE integrent generalement leur propre implementation de 
JMX, tel WebSphere et son implementation developpee par Tivoli. 

Clients JMX 

L'objectif de ces clients JMX est d'offrir une console de supervision afin d'interagir avec 
les MBeans aussi bien par le biais de leurs proprietes que par l'invocation d'actions. 

JConsole 

La version 5 de Java fournit en natif une console de supervision JMX, qui peut etre 
demarree par 1' intermediate du binaire jconsole.exe sous Windows. Elle permet de se 
connecter a des processus Java locaux ou distants. 

Cette console donne acces a des informations concernant le fonctionnement de la 
machine virtuelle aussi bien que des MBeans de 1' application, comme l'illustrent les 
figures 16.3 et 16.4. 

MC4J 

Le projet MC4J, accessible a l'adresse http://mc4j.sourceforge.net/, fournit une implementa- 
tion d'une console de supervision compatible JMX. Elle permet de se connecter a differents 
serveurs JMX par le biais de connecteurs dedies. 

La figure 16.5 illustre le fonctionnement de cet outil. 
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Console de supervision MC4J 



En resume 

La specification JMX fournit un cadre normalise, robuste et eprouve afin de rendre des 
applications Java/J2EE supervisables. Elle decrit les differentes ressources supervisables, 
les entites les gerant et la facon de les acceder depuis des applications externes. 

De nombreux projets Open Source fournissent aussi bien des implementations de serveur 
JMX que des consoles de supervision compatibles avec cette technologie. L'enjeu 
consiste a adresser de maniere optimale 1' integration de cette technologie au sein de ces 
applications. 

La section suivante detaille le support de JMX par Spring visant a integrer cette techno- 
logie dans les applications par declaration. 



Mise en oeuvre de JMX avec Spring 

Spring facilite l'enregistrement et la gestion de Beans simples dans un serveur JMX. Le 
framework construit automatiquement les MBeans correspondant en specifiant les 
proprietes et methodes accessibles par les applications de supervision. 
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L'objectif du support JMX de Spring est d'integrer par declaration cette technologie au 
sein d' applications Java/J2EE utilisant ce framework. Avec Spring, 1' instrumentation des 
composants pour la supervision ne se fait plus au sein du code mais au moment de 
1' assemblage de ces composants par declaration. 

Spring offre egalement la possibility de specifier des metadonnees par le biais notamment 
des annotations, qui permettent d'exporter aisement des informations dans JMX. 

Fonctionnalites du support JMX par Spring 

Grace a de nombreuses fonctionnalites dediees, le support JMX de Spring est tres 
complet. 

Avant de detailler ces fonctionnalites dans les sections suivantes, le tableau 16.2 en 
donne un bref recapitulatif. 



Tableau 16.2. Support JMX de Spring 



Fonctionnalite 


Description 


Exportation des MBeans 


Permet d'enregistrer un composant ou un MBean dans un serveur JMX par decla- 
ration. 


Determination des informations 
exposees dans JMX 


La fonctionnalite precedente doit determiner les informations qui seront utilisees 
et rendues visibles par le serveur JMX. Plusieurs strategies sont fournies afin de 
determiner les metadonnees du composant pour JMX (reflexion, annotations, 
interface, etc.). 


Determination du serveur JMX utilise 


Lexportation offre plusieurs strategies (implicites ou explicites) afin de determiner 
le serveur JMX a utiliser. 


Gestion des noms des MBeans 


Lors de I'exportation des MBeans, un nom doit etre determine afin de les identifier 
dans le serveur JMX. 


Configuration et utilisation 
des connecteurs JSR 160 


Le support offre des facilites afin de mettre en ceuvre des connecteurs JSR 160 
permettant de rendre accessible un serveur JMX ou d'y acceder. 


Configuration et utilisation 
des notifications 


Le support offre des mecanismes afi n d'associer par declaration des observateurs 
a des MBeans et de declencher des evenements. 



Exportation de MBeans 

Spring fournit de nombreuses fonctionnalites permettant d'enregistrer des Beans en tant 
que MBeans dans un serveur JMX. 

Le framework offre egalement diverses approches dans le but de controler les proprietes 
et methodes exposees qui seront visibles et utilisables par les applications de supervision. 

MBean Exporter 

La classe centrale du support JMX, MBeanExporter, localisee dans le package org. spring- 
framework, jmx. export, permet de convertir un composant en un MBean suivant des crite- 
res specifies par declaration et de l'enregistrer automatiquement dans le serveur JMX. 
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Le code suivant donne un exemple simple d' exportation d'un Bean dans JMX avec 
l'identifiant bean:name=testBeanl : 

<beans> 



<bean id="exporter" 

cl ass=" org. springf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean :name=testBeanl" val ue-ref="testBean"/> 
</map> 
</property> 
</bean> 



<bean id="testBean" cl as s= "org. springf ramework. jmx. JmxTestBean"> 

<property name="name" val ue="TEST"/> 

<property name="age" val ue="100"/> 
</bean> 



</beans> 

Des observateurs peuvent etre configures sur cette classe afin d'etre avertis de l'enregis- 
trement ou du desenregistrement d'un MBean. Remarquons que ce mecanisme est propre 
a Spring, et non a JMX. 

Ce type d'observateur doit implementer l'interface MBeanExporterLi stener suivante : 

public interface MBeanExporterListener { 

void mbeanRegi stered(ObjectName objectName) ; 
void mbeanUnregistered(ObjectName objectName); 

} 

L'enregistrement des observateurs de ce type s'effectue grace a la propriete 1 i steners de 
la classe MBeanExporter, cette derniere correspondant a un tableau d'ecouteurs de type 
MBeanExporterLi stener. 

Le code ci-dessous donne un exemple de configuration simple specifiant des ecouteurs : 

<beans> 
<bean id="exporter" 

class=" org. springf ramework. jmx. export. MBean Exporter") 
<property name="listeners"> 
<bean cl ass="MonListenerl"/> 
<bean class="MonListener2"/> 
</property> 
</bean> 
</beans> 

Selection et detection du serveur JMX 

II est possible de laisser Spring detecter automatiquement le serveur JMX present. Cette 
approche est ideale dans le cas oil un serveur JMX est fourni par 1' infrastructure techni- 
que (Java 5 ou serveurs d' applications, par exemple). II est parfois preferable de specifier 
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le serveur JMX souhaite, notamment lorsque 1' application utilise sa propre instance de 
serveur JMX. 

L'approche par detection automatique s'appuie implicitement sur les API de JMX, en 
particulier la methode findMBeanServer de l'interface MBeanServerFactory. Pour sa part, 
l'approche par selection de serveur consiste a injecter explicitement le serveur utilise 
dans le Bean d' exportation, comme dans le code suivant : 

<beans> 

<bean id="mbeanServer" 

class="org.springf ramework. jmx. support. MBeanServerFactory Bean"/> 

<bean id="exporter" 

cl ass=" org. springf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="server" ref="mbeanServer"/> 

</bean> 

<bean id="testBean" class="..."> 

(...) 
</bean> 

</beans> 



Controle des informations exportees 

Nous allons maintenant detailler les diverses approches permettant de controler les infor- 
mations exportees et accessibles par JMX. 

La fonctionnalite de controle des informations exportees permet de parameter la construc- 
tion des MBeans par rapport aux Beans de 1' application. Sa configuration a l'avantage de 
pouvoir etre specifiee au moment de 1' assemblage des composants de 1' application et n'a 
done aucun impact sur 1' application existante. 

L'interface MBeanlnfo Assembler 

L'interface MBeanlnfoAssembler permet de definir l'interface de supervision specifiant les 
informations a exposer pour chaque composant. La classe MBeanExporter delegue ces trai- 
tements a une implementation de cette interface. 

La classe SimpleReflectiveMBeanlnfoAssembler est utilisee par defaut, mais il est possible 
d'en specifier d'autres par 1' intermediate de la propriete assembl er : 

<beans> 
<bean id="exporter" 
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cl ass=" org. spring-framework, jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean :name=testBeanl"> 

<ref local="testBean"/> 
</entry> 
</map> 
</property> 

<property name="assembler"> 
<ref local ="assembler"/> 
</property> 

</bean> 



<bean id="assembler" class="..."> 

(...) 
</bean> 



</beans> 

Les implementations de cette interface ont la responsabilite de creer les informations 
concernant un MBean de type modele a partir d'une instance quelconque, comme l'illustre 
l'exemple suivant de description de cette interface : 

public interface MBeanlnfoAssembler ( 

ModelMBeanlnfo getMBeanInfo(Object managedBean, 

String beanKey) throws JMException; 

} 

Les implementations du controle des informations par le support JMX de Spring selon la 
strategie desiree sont recapitulees au tableau 16.3. 



Tableau 16.3. Implementations du controle des informations 



Implementation 


Description 


Simpl eRefl ecti veMBeanlnfoAssembl er 


Permet de determiner par introspection les informations a rendre visible dans 
JMX. 


MetadataMBeanlnfoAssembl er 


Permet de configurer les strategies de recuperation des metadonnees des 
composants relatives a JMX. 


MethodNameBasedMBeanlnfoAssembl er 


Permet de specifier le nom des methodes utilisables afin de determiner les 
informations a rendre visibles dans JMX. 


MethodExcl usi onMBeanlnfoAssembl er 


Permet de configurer le nom des methodes a ne pas utiliser dans le but de 
determiner les informations a rendre visibles dans JMX. 


InterfaceBasedMBeanlnfoAssembl er 


Permet de specifier le nom des methodes par le biais d'interfaces afin de 
determiner les informations a rendre visibles dans JMX. 



Les sections qui suivent detaillent la facon d'utiliser ces implementations. 
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Lapproche par annotations 

Cette approche s'appuie sur des annotations pour specifier les divers attributs et metho- 
des accessibles par JMX. Le support utilise les informations contenues dans ces annotations 
dans le but de creer le MBean associe. 

Le tableau 16.4 recapitule les differentes annotations fournies par le support JMX de Spring. 
Tableau 16.4. Annotations fournies par le support JMX de Spring 



Annotation 


Description 


ManagedResource 


Permet d'exposer une classe ou interface avec JMX et de specifier ses proprietes 
associees. 


ManagedOperation 


Permet d'exposer une operation avec JMX et de specifier ses proprietes asso- 
ciees. 


ManagedAttribute 


Permet d'exposer un attribut avec JMX et de specifier ses proprietes associees. 


ManagedOperationParameter 


Permet de definir les proprietes concernant les parametres des operations avec 
JMX. 



Le tableau 16.5 fournit les proprietes de ces annotations. 

Tableau 16.5. Proprietes des annotations 



Propriete 


Annotation impactee 


Description 


objectName 


ManagedResource 


Definit I'ObjectName de la ressource. 


description 


ManagedResource, Managed- 
Operation, ManagedAttribute, 
ManagedOperationParameter 


Fournit une description de la ressource. 


currencyTimeLimit 


ManagedResource, Managed- 


Definit la valeur de la propriete currencyTime- 




Attribute 


Limit. 


defaul tVal ue 


ManagedAttribute 


Definit la valeur de la propriete defaul tVal ue. 


log 


ManagedResource 


Definit la valeur de la propriete 1 og. 


1 ogFi 1 e 


ManagedResource 


Definit la valeur de la propriete 1 ogFi 1 e. 


persistPolicy 


ManagedResource 


Definit la valeur de la propriete persi stPol icy. 


persistPeriod 


ManagedResource 


Definit la valeur de la propriete persistPeriod. 


persistLocation 


ManagedResource 


Definit la valeur de la propriete persi stLocation. 


persi stName 


ManagedResource 


Definit la valeur de la propriete persi stName. 


name 


ManagedOperationParameter 


Specifie le nom d'affichage d'un parametre d'une 
operation. 


index 


ManagedOperationParameter 


Specifie I'index d'un parametre d'une operation. 



La configuration de cette approche se realise en specifiant 1' implementation MetadataM- 
BeanlnfoAssembler pour la classe MBeanlnfoExporter. Cette implementation s'appuie sur 
les metadonnees definies dans la classe du Bean. Puisque plusieurs types de metadonnees 
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sont disponibles pour cette classe, une instance de la classe AnnotationsAttributeSource 
doit etre specifiee pour 1' implementation MetadataMBeanlnfoAssembler. 

L'approche par annotations peut etre configured finement afin de specifier les attributs et 
methodes a rendre visibles dans JMX ainsi que leurs proprietes. Elle offre egalement la 
possibility d'alleger la configuration JMX dans Spring puisque les Beans utilisant les 
annotations JMX de Spring peuvent etre detectes et enregistres automatiquement dans le 
serveur. 

Le code ci-dessous donne un exemple de configuration de l'approche par annotations : 

<beans> 

<bean id="exporter" 

cl ass=" org. spring-framework, jinx, export. MBean Exporter "> 
<property name="autodetect" val ue="true"/> 
<property name="issembler"> 
<ref local ="assembler"/> 
</property> 
</bean> 



<bean id="testBean" class="org.springf ramework. jmx. JmxTestBean"> 
<property name="name"> 
<value>TEST</value> 
</property> 
<property name="age"> 
<value>100</value> 
</property> 
</bean> 

<bean id="attributeSource" cl ass="org.springf ramework. jmx. export 
. metadata. AnnotationsAttributeSource"/> 

<bean id="assembler" class="org.springframework. jmx 

.assembler.MetadataMBeanInfoAssembler"> 
<property name="attributeSource"> 
<ref local="attributeSource"/> 
</property> 
</bean> 

</beans> 

Le code suivant decrit un exemple d'implementation du Bean JmxTestBean, configure 
ci-dessus, avec les annotations JMX de Spring : 

@ManagedResource(objectName="bean:name=testBeanl" , 

description="Bean JMX ", log=true, 

1 ogFi 1 e=" jmx. 1 og" , currencyTimeLimi t=15. 

persist Pol icy="Onllpdate" , persi stPeriod=200, 

persistl_ocation="foo" , persi stName=" bar" ) 
public class JmxTestBean { 
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private String name; 
private int age; 

@ManagedAttribute(description="L'attribut name ", 

currencyTimeLimi t=15) 
public String getNameO { 
return name; 

} 

@ManagedOpe rati on (description^ line operation" ) 
public void myOperation( ) { (...) } 

(...) 

} 

L'approche par autodetection 

Dans cette approche, le support JMX de Spring recherche automatiquement les Beans 
qui possedent des informations utilisables pour construire des MBeans JMX. Elle neces- 
site l'utilisation d'une entite d'assemblage implementant l'interface AutodetectCapableM- 
Beanlnfo. La seule implementation de MBeanlnfoAssembler respectant ce critere est la 
classe MetadataMBeanlnfoAssembler decrite precedemment, qui permet d'utiliser des meta- 
donnees de type annotation ou common attribute. 

Avec cette approche, Spring prend comme objectName l'identifiant du Bean pour l'enre- 
gistrer en tant que MBean. 

Pour activer cette approche, la valeur de la propriete autodetect de la classe MBeanExporter 
doit etre positionnee a true, comme dans le code suivant : 

<beans> 
<bean id="exporter" 

cl ass=" org. springf ramework. jmx. export. MBean Exporter "> 
<property name="assembl er" ref="assembl er"/> 
<property name="autodetect" val ue="true"/> 
</bean> 

<bean id="bean :name=testBeanl" 

cl ass=" org. springf ramework. jmx. JmxTest Bean" > 

<property name="name" val ue="TEST"/> 

<property name="age" val ue="100"/> 
</bean> 

<bean id="attributeSource" class="org.springframework 

. jmx. export .metadata .Attributes JmxAttributeSource"/> 

<bean id="assembl er" class="org.springframework. jmx 

. export. assembler. MetadataMBean I nfoAssembler"> 
<property name="attributeSource" ref="attributeSource"/> 
</bean> 
</beans> 
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Remarquons que la configuration de la classe MBeanExporter est alors beaucoup plus 
concise et qu'il n'est plus necessaire de specifier les MBeans a enregistrer au niveau de la 
classe precedente. 

L'approche par interfaces 

Les informations a exposer dans JMX peuvent etre specifiers par 1' intermediate d'inter- 
faces. Cette methode s'appuie sur 1' implementation InterfaceBasedMBeanlnfoAssembler de 
l'interface MBeanlnfoAssembler, qui permet de configurer les interfaces prises en compte, 
comme dans le code suivant : 

<beans> 
<bean id="exporter" 

cl ass=" org. spring-framework, jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key="bean :name=testBean5"> 

<ref 1 ocal ="testBean"/> 
</entry> 
</map> 
</property> 

<property name="assembler">, 
<bean cl ass="org.springf ramework 

.jmx. export .assembl er . InterfaceBasedMBeanlnfoAssembl er"> 
<property name= "managed Interfaces") 

<val ue>org. springf ramework. jmx. IJmxTestBean</val ue> 
</property> 
</bean> 
</property> 
</bean> 

<bean id="testBean" class= "org. springf ramework. jmx. JmxTestBean"> 
<property name="name"> 
<value>TEST</value> 
</property> 
<property name="age"> 
<value>100</value> 
</property> 
</bean> 
</beans> 

L'approche par noms de methodes 

Les methodes et attributs a exposer dans JMX peuvent etre selectionnes en se fondant sur 
leur nom ainsi que sur ceux de leurs accesseurs et mutateurs, informations utilisees lors 
de la creation des MBeans associes. 

Une instance de 1' implementation MethodNameBasedMBeanlnfoAssembler doit etre specifiee 
pour la propriete assembl er de la classe MBeanExporter, comme dans l'exemple ci-dessous : 

<bean id="exporter" 

cl ass=" org. springf ramework. jmx. export .MBeanExporter "> 
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<property name="beans"> 
<map> 

<entry key="bean :name=testBean5"> 

<ref 1 ocal ="testBean"/> 
</entry> 
</map> 
</property> 

<property name="assembl er"> 
<bean class="org.springf ramework. jmx. export 

.assembl er.MethodNameBasedMBeanInfoAssembler"> 
<property name="managedMethods"> 

<val ue>add .myOperati on .getName . setName . getAge</val ue> 
</property> 
</bean> 
</property> 
</bean> 



Gestion des noms des M Beans 

Le support de Spring permet de specifier les noms des MBeans de trois manieres diffe- 
rentes. Les deux premieres consistent a les declarer explicitement lors de la configuration 
de la classe MBeanExporter de Spring, et la troisieme en s'appuyant sur des informations 
contenues dans les metadonnees des composants a exposer dans JMX. 

La premiere approche consiste a definir les noms des MBeans au moment de la configu- 
ration de la classe MBeanExporter. Cette approche n'a aucun impact sur les Beans et ne 
necessite done aucune modification de leur code source. Les Beans ne sont pas dans 
l'obligation de suivre les conventions de codage imposees par certains types de MBeans. 

Les Beans a exporter sont specifies par 1' intermediate de la propriete beans de type Map. 
Les cles de cette table de hachage correspondent aux noms JMX, et les valeurs font refe- 
rence aux instances des Beans. 

Le code suivant donne un exemple de mise en ceuvre de cette fonctionnalite : 

<beans> 
<bean id="exporter" 

class="org.springf ramework. jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBeanl" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="server" ref="mbeanServer"/> 
</bean> 

<bean id="testBean" cl ass="org.springf ramework. jmx. JmxTestBean"> 

<property name="name" val ue="TEST"/> 

<property name="age" val ue="100"/> 
</bean> 
</beans> 
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La deuxieme approche consiste a extemaliser la definition des noms des MBeans JMX 
dans un fichier de proprietes. Dans ce cas, la cle de la table de hachage de la propriete 
beans de la classe MBeanExporter correspond non plus a un ObjectName, mais a une refe- 
rence qui est resolue par le biais d'une instance de l'interface ObjectNamingStrategy. 
L' implementation KeyNamingStrategy de cette interface met alors en oeuvre une resolution 
en utilisant un fichier de proprietes ou une table de hachage. 

Le code suivant donne un exemple d'utilisation de la classe KeyNamingStrategy avec la 
classe MBeanExporter : 

<beans> 
<bean id="exporter" 

cl ass=" org. spring-framework, jinx, export. MBeanExporter") 
<property name="beans"> 
<map> 

<entry key="testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="namingStrategy" ref="namingStrategy"/> 

</bean> 

<bean id="testBean" class="org.springf ramework. jmx. JmxTestBean"> 

<property name="name" val ue="TEST"/> 

<property name="age" val ue="100"/> 
</bean> 

<bean id="namingStrategy" cl ass="org.springf ramework. jmx. export 

. nami ng . KeyNami ngStrategy "> 

<property name="mappings"> 
<props> 

<prop key="testBean">bean:name=testBean</prop> 
</props> 
</property> 

<property name="mappingLocations"> 
<value>names. properties </value> 
</property> 
</bean> 

</beans> 

Par exemple, le code du fichier de proprietes names.properties est de la forme : 

testBeanl=bean:name=testBeanl 

Dans la troisieme approche, le nom du MBean est specifie dans la propriete objectName de 
l'annotation ManagedResource. 

La section precedente relative aux annotations fournit de plus amples details sur leur 
utilisation. 
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Les connecteurs JSR 160 

Les connecteurs adressent le niveau services distribues afin de permettre l'acces a un 
serveur JMX distant. 

La specification JMX distingue deux types de connecteurs. Le premier est mis en oeuvre 
conjointement avec le serveur JMX de maniere a le rendre accessible. Le second doit 
pour sa part etre utilise dans l'application desirant se connecter au serveur distant. 

Les connecteurs serveurs 

Dans la plupart des cas, ces connecteurs sont deja presents dans 1' infrastructure JMX 
fournie. Concernant les serveurs d' applications, ces connecteurs sont automatiquement 
associes et demarres pour les composants du niveau agent de JMX. Ajoutons que l'utili- 
sation d'un serveur JMX dedie favorise la mise en pratique de connecteurs serveurs dans 
certaines applications. 

Spring supporte cette fonctionnalite par 1' intermediate de la classe ConnectorServerFac- 
toryBean, localisee dans le package org. springf ramework. jmx. support. Cette entite offre la 
propriete objectName afin de s'enregistrer automatiquement dans le serveur JMX. Le 
connecteur peut egalement etre execute dans un nouveau fil d' execution grace a la 
propriete threaded. 

Le code suivant donne un exemple de configuration d'un connecteur fonde sur le proto- 
cole RMI : 

(...) 

<bean id="registry" class="org. spring-framework. 

remoting. rmi . Rmi Registry FactoryBean"> 
<property name="port" val ue="1099"/> 
</bean> 

<bean id="serverConnector" class="org.springframework. 

jmx. support .ConnectorServer Factory Bean" > 
<property name="server" ref="mbeanServer" /> 
<property name="objectName" val ue="connector:name=rmi "/> 
<property name="serviceUrl " 

val ue="servi ce: jmx: rmi : //local host/jndi/ 

rmi : //l oca 1 host :1099/my connector "/> 
<property name="threaded" val ue="true"/> 
</bean> 

Les connecteurs clients 

Ce type de connecteur permet l'acces a un serveur JMX distant associe a un connecteur 
serveur depuis une application cliente. Spring fournit alors la classe MBeanServerConnec- 
tionFactoryBean dans le meme package que precedemment. Sa seule propriete obligatoire 
est serviceUrl, qui permet de definir l'adresse d'acces au connecteur tout en indiquant le 
protocole utilise. 
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Le code suivant en donne un exemple de mise en oeuvre permettant d'utiliser le connecteur 
serveur decrit a la section precedente : 

<bean id="cl ientConnector" class="org.springframework. 

jmx. support .MBeanServerConnect ion Factory Bean" > 
<property name="serviceUrl " 

val ue="service: jmx: rmi : //local host/jndi / 

rmi ://l ocal host: 1099/my connector "/> 

</bean> 

Les notifications 

Le support des notifications a ete integre au support JMX avec la version 2.0 de Spring. 
II s'appuie sur la classe MBeanExporter du package org. spring-framework, jmx. export. 

Cette classe fournit une propriete notification Listeners de type Map afin de configurer les 
differents observateurs, comme dans le code suivant : 

<bean id="exporter" 

cl ass="org. spring-framework, jmx. export .MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key="testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="notifi cation Li steners"> 
<map> 

<entry key="*" val ue-ref="jmxListener"/> 
</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 

<bean id="jmxListener" class="MyJmxListener"/> 

La classe MBeanExporter peut egalement etre mise en oeuvre exclusivement pour definir 
des observateurs sur des MBeans precedemment enregistres. 

Une utilisation courante correspond a la configuration d' observateurs pour la classe MBean- 
ServerDelegate. Elle permet de recevoir notamment les evenements correspondant aux 
enregistrements ou desenregistrements de MBeans, comme dans 1' exemple ci-dessous : 

<bean id="exporter" 

cl ass="org.springf ramework. jmx. export .MBeanExporter "> 
<property name="notif i cation Li steners"> 
<map> 

<entry key=" JMImplementation:type=MbeanServerDelegate" 

val ue-ref="jmxLi stener"/> 

</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 

<bean id="jmxListener" cl ass="MyJmxLi stener"/> 
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En resume 

Le support JMX de Spring offre un cadre flexible pour utiliser et configurer les elements 
des differents niveaux de cette technologie. Au moment de 1' assemblage des composants, 
le developpeur choisit la facon dont sont enregistres les Beans dans le serveur JMX. Le 
support peut utiliser aussi bien un serveur dedie a 1' application qu'un serveur fourni par 
l'environnement d'execution, tel qu'un serveur d' applications. La facon d'acceder au 
serveur JMX peut egalement etre configured lors de l'assemblage de l'application. 

Les atouts de ce support sont la simplification de 1' utilisation de JMX et le fait que Spring 
peut ainsi etre utilise simplement, aussi bien dans des applications J2EE que dans des 
applications Java autonomes 



Tudu Lists : utilisation du support JMX de Spring 

Le projet Tudu-SpringMVC illustre de quelle facon mettre en oeuvre le support JMX de 
Spring afin d'utiliser les outils JMX d'Hibernate et ainsi de recuperer des informations 
concernant les appels aux services de l'application. 

Nous separerons la configuration des elements relatifs a JMX dans le fichier de Spring 
applicationContext-jmx.xml, localise dans le repertoire WEB-INF et utilise par le 
contexte de l'application Web. 

Pour la configuration du serveur JMX, nous choisissons d'embarquer dans notre applica- 
tion notre propre serveur JMX, de facon a demontrer la facilite de mise en oeuvre d'un 
serveur JMX, et ce quel que soit le type d' application Java/J2EE fonde sur Spring 
concerne. Nous utilisons 1' implementation MX4J de JMX. 

Pour determiner 1' implementation JMX utilisee, la propriete javax. management. buil - 
der. initial precedemment decrite doit etre specifiee dans la ligne de commande du 
serveur avec la valeur mx4j. server. MX4JMBeanServerBui 1 der. Les bibliotheques JMX et 
MX4J suivantes doivent en outre etre ajoutees dans le classpath : jmxremote_optional .jar, 
jmxremote. jar, jmxri .jar et mx4j .jar. 

Le code suivant illustre la configuration du serveur JMX dans le fichier application- 
Context-jmx.xml du repertoire WEB-INF : 

<bean id="mbeanServer" 

cl as s= " o rg.springframework. jmx. support. MBeanServer Factory Bean" /> 

Dans le but de rendre ce serveur accessible depuis des consoles de supervision telles que 
MC4J, notre choix se porte sur la configuration d'un connecteur JMX fonde sur le proto- 
cole RMI. Ce choix impose la mise en oeuvre d'un serveur RMI au cceur de notre 
application en s'appuyant sur les facilites de Spring, comme dans le code suivant : 

<bean id="registry" 

class="org.springframework.remoting.rmi . Rmi Regis try Factory Bean "> 
<property name="port" val ue="1099"/> 
</bean> 
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<bean id="serverConnector" class="org. spring-framework. jmx 

.support .ConnectorServer Factory Bean" > 
<property name="server" ref="mbeanServer" /> 
<property name="objectName" val ue="connector:name=rmi "/> 
<property name="servicellrl " val ue=" service: jmx: rmi ://l oca 1 host 

/jndi/rmi : //local host: 1099/tudu"/> 
<property name="threaded" val ue="true"/> 
</bean> 

Precisons que, dans le code ci-dessus, le serveur JMX est disponible par le biais du proto- 
cole RMI a l'adresse service: jmx:rmi ://local host/jndi /rmi ://local host: 1099/tudu. De 
plus, le connecteur JMX est execute dans un fil d' execution dedie. 

Nous configurons desormais l'acces au serveur dans la console MC4J. Nous creons tout 
d'abord une nouvelle connexion a un serveur puis selectionnons un type de connexion 
fonde sur JSR 160. L' utilisation de la classe RegistryContextFactory du package 
com. sun. jndi .rmi .registry pour cette connexion est necessaire, avec en parametre 
l'adresse RMI precedemment configuree. 

La figure 16.6 illustre la fenetre de configuration de MC4J. 



Figure 16.6 
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Nous mettons alors en ceuvre l'adaptateur fourni par MX4J pour le protocole HTTP 
grace a la classe HttpAdapter localisee dans le package mx4j. tools. adaptor. http. Cette 
derniere se parametre en tant que Bean dans le contexte de Spring : 

<bean i d="httpAdaptor" cl ass="mx4j . tool s . adaptor . http. HttpAdaptor" 
init-method="start" destroy-method="stop"> 
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<property name="host" value="localhost"/> 
<property name="port" val ue="7777"/> 
</bean> 

Enfin, nous configurons et implementons les divers elements relatifs a la supervision. 
Dans notre application, les noms des differents MBeans exposes dans JMX sont prefixes 
par convention par tudu: services 

Utilisation d'Hibernate 

Dans un premier temps, nous utilisons le MBean JMX fourni par le framework Hibernate 
pour la supervision, tout en obtenant des informations concernant 1' utilisation des 
ressources JDBC, la gestion des entites, l'execution des requetes ainsi que les caches. 

Nous implementons ce MBean par le biais de la classe StatisticsService du package 
org. hibernate, jmx, qui peut etre configuree dans Spring de la maniere suivante : 

<bean name="hi bernateStati sti cs" 

cl ass="org. hibernate. jmx. StatisticsService"> 
<property name="sessionFactory" ref="sessionFactory"/> 
</bean> 

<bean id="exporter" 

class="org.springf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="tudu:service=hi bernateStati sties" 

val ue-ref ="hi bernateStati sti cs" /> 

</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 

Tudu Lists utilise le support de la classe MBeanExporter de Spring decrite precedemment 
afin de rendre le MBean d'identifiant hi bernateStati sties disponible dans JMX avec le 
nom tudu: service: hi bernateStati sties. 

Le service todoListsManager 

Nous cherchons maintenant a instaurer un mecanisme fonde sur JMX afin d'identifier les 
appels au service todoListsManager dans Spring. 

Dans cette optique, nous implementons un intercepteur AOP qui incremente un compteur 
a chaque appel des methodes du service. Nous exposons ensuite cette entite dans JMX 
afin d'acceder aux valeurs du compteur et eventuellement de le reinitialiser. 

L' intercepteur est implemente grace a la classe TodoListsManagerlnterceptor localisee 
dans le package tudu. service. impl : 

public class TodoListsManagerlnterceptor 

implements Methodlnterceptor ( 
private long numberOfCall=0; 

public Object invoketMethodlnvocation invocation) 
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throws Throwable 



numberOfCall-H-; 

return invocation. proceedt ) 



public long getNumberOfCal 1 ( ) { 
return numberOfCal 1 ; 

} 



publ ic void resett ) { 
numberOfCall=0; 

} 

} 

Le Bean todoListsManager se situe deja derriere un proxy de type TransactionProxyFacto- 
ryBean de maniere a realiser la demarcation transactionnelle. Ce type de proxy offre la 
possibility d'en ajouter un autre dans la liste des intercepteurs par l'intermediaire de 
la propriete prelnterceptors. 

Le code suivant illustre la configuration de notre intercepteur : 

<bean id="todoListsManager Interceptor" 

cl ass="tudu. service. imp! . TodoListsManager I nterceptor"/> 

<bean id=" todoListsManager" cl ass=" org. springframework. transact ion 
.interceptor .Transact!' on Proxy Factory Bean "> 
<property name="transactionManager"> 
<ref bean="transactionManager" /> 
</property> 

<property name="target"> 

<ref 1 ocal ="todoLi stsManagerTarget" /> 
</property> 

<property name="preInterceptors"> 
<list> 

<ref local="todoListsManagerInterceptor"/> 
</list> 
</property> 

<property name=" transaction Attributes'^ 
<props> 

<prop key=" create*" >PROPAGATION_REQU I RED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="del ete*">PROPAGATION_REQUIRED</prop> 
<prop key="add*">PROPAGATION_REQUIRED</prop> 
<prop key="restore*">PROPAGATION_REQUIRED</prop> 
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 
</property> 
</bean> 

Pour enregistrer cet intercepteur dans JMX, nous utilisons les fonctionnalites du 
framework Spring par l'intermediaire de la classe MBeanExporter : 

<bean id="exporter" 

cl ass="org.springf ramework. jmx. export .MBeanExporter "> 
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<property name="beans"> 
<map> 

<entry key="tudu:service=todoListsManager Interceptor" 
val ue-ref="todoListsManagerInterceptor" /> 

</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 



La supervision 



Une fois notre infrastructure JMX en place et nos differents MBeans enregistres dans le 
serveur JMX, nous pouvons observer revolution de leurs multiples proprietes grace a la 
console MC4J et ses outils graphiques. 

Dans un premier temps, nous demarrons Tomcat, puis nous nous connectons depuis la 
console MC4J sur le serveur JMX embarque. Nous constatons 1' apparition des differents 
MBeans du serveur, incluant ceux concernant Hibernate et les services de Tudu Lists. 

La figure 16.7 illustre l'arborescence des MBeans dans la console MC4J. 
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Figure 16.7 

Hierarchie des MBeans dans la console MC4J 



La console permet egalement de visualiser en temps reel et de maniere graphique la 
valeur de lapropriete numberOfCall de l'intercepteur du service todoListsManagerlnterceptor, 
comme l'illustre la figure 16.8. 
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Figure 16.8 

Courbe d' evolution des valeurs de la propriete numberOfCall 



La console permet egalement de consulter des statistiques d'utilisation d'Hibernate, 
telles que le nombre d'entites chargees depuis le demarrage de l'application, comme 
l'illustre la figure 16.9. 

Grace a un adaptateur pour le protocole HTTP, nous pouvons egalement visualiser les 
differents MBeans dans un navigateur Web au format XML, le format par defaut de 
MX4J. 
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Figure 16.9 
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Affichage ties MBeans dans un navigateur Web 
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Conclusion 

Le support JMX de Spring offre une grande flexibilite d' utilisation, ainsi que de 
nombreuses fonctionnalites qui facilitent sa mise en ceuvre au sein des applications 
d'entreprise. Les divers composants en jeu se configurent directement et simplement 
dans le contexte de Spring. 

Differentes strategies sont fournies pour permettre de determiner precisement les 
proprietes et methodes a rendre accessibles dans JMX. II est egalement possible d'expo- 
ser de maniere transparente de simples Beans. Ainsi, des composants peuvent etre exposes 
dans JMX au moment de 1' assemblage de 1' application sans aucun developpement 
supplemental. 

Le support fournit enfin un ensemble de classes qui rendent possible d'embarquer son 
propre serveur JMX, ainsi que de se connecter et d'interagir avec diverses entites de 
JMX, comme les connecteurs et les observateurs de MBeans. 
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Les tests sont une des activites fondamentales du developpement logiciel. Ce chapitre 
montre comment tester une application reposant sur Spring. Les types de tests abordes 
sont les tests unitaires et les tests d'integration. 

Par tests unitaires, nous entendons les tests portant sur un composant unique isole du 
reste de 1' application et de ses composants techniques (serveur d' applications, base de 
donnees, etc.). Par tests d'integration, nous entendons les tests portant sur un ou plusieurs 
composants, avec les dependances associees. II existe bien entendu d'autres types de 
tests, comme les tests de performance ou les tests fonctionnels, mais Spring ne propose 
pas d'outil specifique dans ces domaines. 

Nous nous arreterons de maniere synthetique sur deux outils permettant de realiser des tests 
unitaires, le framework JUnit et EasyMock, ce dernier permettant de realiser des simu- 
lacres d'objets, ou mock objects. Ces deux outils nous fourniront l'occasion de detailler 
les concepts fondamentaux des tests unitaires. Nous verrons que l'utilisation de ces outils 
est toute naturelle pour les applications utilisant Spring, puisque le code de ces 
dernieres ne comporte pas de dependance a l'egard de ce framework du fait de l'inver- 
sion de controle. Spring propose d'ailleurs ses propres simulacres pour emuler une 
partie de l'API J2EE. 

Pour les tests d'integration, nous nous interesserons aux extensions de JUnit fournies par 
Spring et par le framework StrutsTestCase, specialise dans les tests de composants Web 
utilisant Struts. La encore, les tests s'averent aises a implemented ces extensions 
masquant la complexite de mise en oeuvre de ces deux frameworks. 
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Les tests unitaires avec JUnit 

JUnit est un framework Java Open Source cree par Erich Gamma et Kent Beck. II fournit 
un ensemble de fonctionnalites permettant de tester unitairement les composants d'un 
logiciel ecrit en Java. D'autres frameworks suivant la meme philosophie sont disponibles 
pour d'autres langages ou pour des technologies specifiques, comme HTTP. lis constituent 
la famille des frameworks xUnit. 

Initialement concu pour realiser des tests unitaires, JUnit peut aussi etre utilise pour realiser 
des tests d'integration, comme nous le verrons plus loin dans ce chapitre. 

Dans les sections suivantes, nous indiquons comment manipuler les differents elements 
fournis par JUnit afin de creer des tests pour Tudu Lists. Dans cette application, 1' ensemble 
des cas de tests est regroupe dans le repertoire Tests. Les differents tests sont organises selon 
les classes qu'ils ciblent. Ainsi, ils reproduisent la structure de packages de Tudu Lists. 

Les cas de test 

Les cas de test sont une des notions de base de JUnit. II s'agit de regrouper dans une 
entite unique, en l'occurrence une classe Java derivant de junit. framework. TestCase, un 
ensemble de tests portant sur une classe de 1' application. 

Chaque test est materialise sous la forme d'une methode sans parametre, sans valeur de 
retour et dont le nom est prefixe conventionnellement par test (par exemple, testEqual s). 
Le nom de la classe regroupant les tests d'une classe est conventionnellement celui de la 
classe testee suffixee par Test (par exemple, TodosManagerlmplTest). 

Squelette d'un cas de test 

Pour introduire la notion de cas de test, nous allons utiliser la classe Todo definie dans le 
package tudu. domain. model. Cette classe definit deux methodes, compareTo (methode de 
l'interface java.lang. Comparable) et equals (heritee de java.lang. Object). 

Pour tester ces deux methodes, nous allons creer plusieurs instances de la classe Todo et 
effectuer des comparaisons ainsi que des tests d'egalite. Nous definissons pour cela une 
classe TodoECTest ayant deux methodes, testCompareTo et testEqual s : 

package tudu. domain. model ; 

import junit. framework. TestCase; 

public class TodoECTest extends TestCase { 

public TodoECTest(String name) { 
super(name) ; 

} 

(...) 

public void testCompareTo( ) { 
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(...) 

} 

public void testEqualsO { 
(...) 

} 

} 

Notons la presence d'un constructeur faisant appel directement a celui de l'ancetre de la 
classe. Ce constructeur est utile pour la methode addTest de la classe j unit . framework. Test- 
Sui te, comme nous le verrons plus loin. 

La notion de fixture 

Dans JUnit, la notion de fixture, ou contexte, correspond a un ensemble d'objets utilises 
par les tests d'un cas. Typiquement, un cas est centre sur une classe precise du logiciel. II 
est done possible de definir un attribut ayant ce type et de l'utiliser dans tous les tests du 
cas. II devient alors une partie du contexte. Le contexte n'est pas partage par les tests, 
chacun d'eux possedant le sien, afin de leur permettre de s'executer independamment les 
uns des autres. 

II est possible de definir deux methodes specifiques pour gerer le contexte : la methode 
setup pour son initialisation et la methode tearDown pour sa destruction, setup est appelee 
avant 1' execution, et tearDown a la fin de l'execution de chaque methode de test. 

Ces deux methodes se presentent de la maniere suivante : 

public class TodoECTest extends TestCase { 

protected void setUpO throws Exception { 
// Creation du contexte 

} 

protected void tearDownO throws Exception { 
// Destruction du contexte 

} 

(...) 

} 

Pour les tests de la classe Todo, nous pouvons creer un ensemble d'attributs de type Todo 
qui nous serviront de jeu d'essai pour nos methodes de test : 

public class TodoECTest extends TestCase { 

private Todo todol; 
private Todo todo2; 
private Todo todo3; 



protected void setUpO throws Exception { 
todol = new Todo( ) ; 
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todol.setTodoIdC'Ol"); 
todol .setCompl eted(fal se) ; 
todol.setDescription( "Description" ) ; 
todol. setPriority(O) ; 

todo2 = new Todo( ) ; 
todo2.setTodoId("02") ; 
todo2.setCompleted(true) ; 
todo2.setDescription( "Description" ) ; 
todo2.setPriority(0) ; 

todo3 = new Todo( ) ; 
todo3.setTodoId("01"); 
todo3. setCompl eted(fal se) ; 
todo3.setDescription( "Description" ) ; 
todo3.setPriority(0) ; 



(...) 

} 



Les assertions et I'echec 

Dans JUnit, les assertions sont des methodes permettant de comparer une valeur obtenue 
lors du test avec une valeur attendue. Si la comparaison est satisfaisante, le test peut se 
poursuivre. Dans le cas contraire, il echoue, et un message d'erreur s'affiche dans l'outil 
permettant d'executer les tests unitaires (voir plus loin). 

Les assertions sont heritees de la classe junit. framework. TestCase. Leur nom est prefixe 
par assert. 

Pour les booleens, les assertions suivantes sont disponibles : 

assertEquals (boolean attendu, boolean obtenu); 
assertFalse (boolean obtenu); 
assertTrue (boolean obtenu); 

La premiere assertion permet de verifier l'egalite de la valeur obtenue par rapport a une 
autre variable. Les deux autres testent le booleen obtenu sur les deux valeurs litterales 
possibles, faux ou vrai. 

Pour les objets, les assertions suivantes sont disponibles, quel que soit leur type : 

assertEquals (Object attendu, Object obtenu); 
assertSame (Object attendu, Object obtenu); 
assertNotSame (Object attendu, Object obtenu); 
assertNull (Object obtenu); 
assertNotNul 1 (Object obtenu); 

assertEqual s teste l'egalite de deux objets tandis qu'assertSame teste que attendu et obtenu 
font reference a un seul et meme objet. Par exemple, deux objets de type java.util .Date 
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peuvent etre egaux, c'est-a-dire contenir la meme date, sans etre pour autant un seul et 
meme objet. assertNotSame verifie que deux objets sont differents. Les deux dernieres 
assertions testent si 1' objet obtenu est nul ou non. 

Pour chaque type primitif (int, byte, etc.), une methode assertEqual s est definie, permet- 
tant de tester l'egalite entre une valeur attendue et une valeur obtenue. Dans le cas des 
types primitifs correspondant a des nombres reels (float, double), un parametre supple- 
mentary le delta, est necessaire, car les comparaisons ne peuvent etre tout a fait exactes 
du fait des arrondis. 

II existe une variante pour chaque assertion prenant une chaine de caracteres en premier 
parametre (devant les autres). Cette chaine de caracteres contient le message a afficher si 
le test echoue au moment de son execution. 

Les assertions ne permettent pas de capter tous les cas d'echec d'un test. Pour ces cas de 
figure, JUnit fournit la methode f ai 1 sous deux variantes : une sans parametre et une avec 
un parametre, permettant de donner le message d'erreur a afficher sous forme de chaine 
de caracteres. L'appel a cette methode entraine 1' arret immediat du test en cours et l'affiche 
en erreur dans l'outil d'execution des tests unitaires. 

Si nous reprenons notre exemple TodoECTest, il se presente desormais de la maniere suivante : 
public class TodoECTest extends TestCase { 

(...) 

public void testCompareTo( ) { 

// Verifie la consistance avec la methode equals 
// Cf . JavaDoc de 1 'API J2SE 
assertTruettodol . compareTo(todo3)==0) ; 

// Verifie le respect de la spec de Comparable pour null 
// Cf . JavaDoc de 1 'API J2SE 
try { 

todol. compareTotnull ); 
failO; 

} 

catch(Nul 1 PointerException e){ 
} 

// todol n'est pas ferme done < a todo2 
assertTrue(todol .compareTo(todo2)<0) ; 

// Verifie que 1 'inverse est vrai aussi 
assertTrue(todo2.compareTo( todol )>0) ; 

} 

public void testEqualsO { 
assertEqual s( todol ,todo3) ; 
assert Fal set todol .equal s(todo2) ) ; 
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Les suites de tests 

Les cas de test sont generalement tres nombreux pour un logiciel. Afin de simplifier le 
lancement de ces differents tests, il peut etre interessant de les regrouper dans un ou 
plusieurs ensembles permettant de commander leur execution de maniere collective. 

Dans JUnit, de tels ensembles sont appeles des suites de tests. Une suite de tests est defi- 
nie grace a la classe j unit .framework. TestSuite du framework. Pour cela, il suffit de creer 
une instance de cette classe et d'utiliser ses methodes addTest et addTestSuite. 

La methode addTest 

La methode addTest est utilisee pour ajouter un test unique a la suite, c'est-a-dire une 
methode test particuliere. Par exemple, pour TodoECTest, si nous desirons creer une suite 
executant les tests des methodes compareTo et equals, nous ecrivons le code suivant : 

TestSuite suite = new TestSuiteCTest de compareTo et equals") ; 
suite. addTesttnew TodoECTest( "testCompareTo" ) ) ; 
suite. addTesttnew TodoECTest( "testEqual s" ) ) ; 

Nous constatons que nous utilisons le constructeur de TodoECTest pour selectionner le test 
a inclure dans la suite, d'ou l'importance de le definir, faute de quoi il n'est pas possible 
d'inclure specifiquement une des methodes du cas de test. 

La methode addTestSuite 

La methode addTestSuite permet d'inclure automatiquement tous les tests contenus dans 
un cas de test. 

Supposons que nous ayons deux cas de test, TodoECTest et TodoListTest. Le code suivant 
montre comment creer une suite permettant de regrouper la totalite de leurs tests dans 
une seule et meme suite : 

TestSuite suite = new TestSuitet "Tests de TodoECTest et TodoListTest"); 
suite. addTestSuite (TodoECTest. class) ; 
suite.addTestSuite(TodoListTest.cl ass) ; 

Encapsulation d'une suite 

Pour executer une suite de tests, il est necessaire de creer une classe, qui sera utilisee par 
un des lanceurs de JUnit. Cette classe doit comporter une methode statique sans parametre, 
appelee suite, renvoyant un objet de type junit. framework. Test (il s'agit d'une interface 
implemented notamment par junit. framework. TestSuite). 

Pour Tudu Lists, nous avons defini la classe Al 1 Tests dans le package tudu.testsuite pour 
executer en un seul appel l'ensemble des tests unitaires du projet : 

package tudu.testsuite; 
(...) 

public class AllTests { 
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public static Test suiteO ( 

TestSuite suite = new TestSuiteC'Tests for tudu.*"); 

suite.addTestSuitet TodoECTest. class) ; 

suite. addTestSuitetAuthenticationDAOImpl Test. class) ; 

suite.addTestSuite(ConfigurationManagerImpl Test. class) ; 

suite.addTestSuite(TodoLi stsManagerlmplTest.cl ass) ; 

(...) 

return suite; 

} 



Execution des tests 

Une fois les cas de test et les suites de tests definis, il est necessaire de les executer pour 
verifier le logiciel. 

Les lanceurs standards de JUnit 

Comme explique precedemment, JUnit propose plusieurs lanceurs standards (TestRunners) 
pour executer les cas de test et les suites de tests : 

• lanceur en mode texte ; 

• lanceur en mode graphique reposant sur la bibliotheque AWT ; 

• lanceur en mode graphique reposant sur la bibliotheque Swing. 

Pour utiliser le lanceur en mode texte dans un cas de test (ici la classe TodoECTest), il suffit 
d'y ajouter une methode main de la maniere suivante : 

public static void main(String[] args) { 

juni t .textui . Tes t Runner . run (TodoECTest. cl ass) ; 

} 

La classe junit. textui .TestRunner est appelee en lui passant en parametre la classe du 
cas de test (et non une instance) a executer. Cette methode main peut etre ecrite soit 
directement dans la classe du cas de test, comme dans cet exemple, soit dans une classe 
specifique. 

Si nous executons TodoECTest, nous obtenons le resultat suivant dans la console Java : 



Time: 0,091 
OK (2 tests) 



Ce resultat indique de maniere laconique que les deux tests definis dans TodoECTest se 
sont bien executes. 
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Pour utiliser le lanceur fonde sur AWT, il faut coder la methode mai n comme ceci : 

public static void main(String[] args) { 

juni t .awtui .Test Runner. runtTodoECTest . cl ass) ; 

I > 

Si nous executons TodoECTest, la fenetre illustree a la figure 17.1 s'affiche. 



Figure 17.1 

Le lanceur fonde sur AWT 



JUnit 

Test class name: 



|tududomain.model.TodoECTest 
15 Reload classes every run 



Runs: 2 Errors: 
Errors and Failures: 



Finished: 0,03 seconds 



Failures: 



Run 



u 



Run 



Exit 



De la meme maniere, pour utiliser le lanceur fonde sur Swing, il suffit de modifier lege- 
rement le code de la methode mai n precedent (changement en gras) : 

public static void main(String[] args) { 

junit.swingui .Test Runner. run (TodoECTest. class) ; 

} 

Si nous executons TodoECTest, la fenetre illustree a la figure 17.2 s'affiche. 

Nous pouvons constater que le lanceur Swing est plus sophistique graphiquement que 
celui fonde sur AWT (presence d'onglets pour visionner les echecs et la hierarchie des 
tests). 

Pour executer une suite de tests, la demarche est similaire. II faut creer une methode main 
utilisant la methode sui te. Pour la suite Al 1 Tests creee precedemment, elle se presente de 
la maniere suivante : 

public static void main(String[] args) { 

j unit, text ui .Test Runner, run (All Tests, sui teO) ; 
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Figure 17.2 

Le lanceur fonde sur Swing 
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Finished: 0,09 seconds 



Exit 



Le lanceur prend comme parametre le resultat de la methode sui te (en gras dans le code) 
pour connaitre les tests a executer. Cette methode mai n peut etre definie soit dans la meme 
classe que la methode suite, soit dans une classe specifique. 



Le lanceur JUnit integre a Eclipse 

Eclipse propose son propre lanceur JUnit, parfaitement integre a l'environnement de 
developpement. 

Pour l'utiliser, il n'est pas necessaire de creer une methode main specifique dans les 
cas de test, a la difference des lanceurs standards. II suffit de selectionner l'explora- 
teur de package et le fichier du cas de test ou de la suite par clic droit et de choisir Run 
dans le menu contextuel. Parmi les choix proposes par ce dernier, il suffit de selectionner 
JUnit Test. 

Une vue JUnit s'ouvre alors pour nous permettre de consulter le resultat de l'execution 
des tests. Si tel n'est pas le cas, nous pouvons l'ouvrir en choisissant Window puis Show 
view et Other. Une liste hierarchisee s'affiche, dans laquelle il suffit de selectionner JUnit 
dans le dossier Java et de cliquer sur le bouton OK (voir figure 17.3). 

L'interet de ce lanceur reside dans sa gestion des echecs apres l'execution des tests. 
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Figure 17.3 

Vue JUnit integree 
a Eclipse 



Package Explorer Navigator 



Finished after 0,06 seconds 
Runs: 2/2 o Errors: 0 



o Failures: 0 



o Q Failures J- Hierarchy 
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Si nous modifions TodoECTest de maniere que deux tests echouent (il suffit pour cela de 
mettre une valeur attendue absurde, qui ne sera pas respectee par la classe testee), nous 
obtenons dans le lanceur le resultat illustre a la figure 17.4. 



Figure 17.4 
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= Failure Trace - 

' junit.framework.Assert'ionFailedError 
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= at sun.reflect.NativeMethodAccessorImpl.invokeO(Na 
= at sun.reflect.NativeMethodAccessorImpl.invoke(Unk 
= at sun.reflect.DelegatingMethodAccessorlmpl.invoke 
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Les echecs (failures) sont indiques par une croix bleue et les succes par une marque 
verte. En cliquant sur un test ayant echoue, la trace d' execution est affichee dans la zone 
Failure Trace. En double-cliquant sur le test, son code source est immediatement affiche 
dans l'editeur de code d' Eclipse. 

A partir des resultats des tests, le developpeur peut naviguer directement dans son code et 
le corriger dans Eclipse, ce qui n'est pas possible avec les lanceurs standards de JUnit. 

En resume 

L'ecriture de tests avec JUnit n'est pas intrinsequement compliquee. Cependant, il faut 
garder a l'esprit que cette simplicite d'utilisation depend fortement de la facon dont 
1' application est concue. La mise en oeuvre de tests unitaires dans une modelisation 
naive, a l'image de celle que nous avons presentee au chapitre 2, s'avere tres difficile 
(d'ou notre critere d'inverifiabilite). 

L' utilisation de JUnit est rendue efficace grace aux principes architecturaux que doivent 
appliquer les applications Spring, a savoir 1' inversion de controle apportee par le conte- 
neur leger et la separation claire des couches de 1' application. Grace a ces principes, les 
composants se revelent plus simples a tester, car ils se concentrent dans la mesure du 
possible sur une seule preoccupation. 

En complement de JUnit, il est necessaire d'utiliser des simulacres d'objets arm d'isoler 
des contingences exterieures le composant a tester unitairement. C'est ce que nous allons 
voir a la section suivante. 

Les simulacres d'objets 

Le framework JUnit constitue un socle pour realiser des tests, mais il n'offre aucune 
fonctionnalite specifique pour tester les relations entre les differents objets manipules 
lors d'un test. II est de ce fait difficile d'isoler les dysfonctionnements de l'objet teste de 
ceux qu'il manipule, ce qui n'est pas souhaitable lorsque nous realisons des tests unitaires, 
par exemple. 

Afin de combler ce vide, il est possible d'utiliser des simulacres d'objets (mock objects). 
Comme leur nom l'indique, ces simulacres simulent le comportement d'objets reels. II 
leur suffit pour cela d'heriter de la classe ou de l'interface de l'objet reel et de surcharger 
chaque methode publique utile au test. Le comportement de ces methodes est ainsi rede- 
fini selon un scenario concu specifiquement pour le test unitaire et done parfaitement 
maitrise. 

Par exemple, si nous testons un objet faisant appel a un DAO, nous pouvons remplacer ce 
dernier par un simulacre. Ce simulacre ne se connectera pas a la base de donnees mais 
renverra des donnees statiques specialement definies pour le test unitaire. Nous isolons 
de la sorte l'objet teste des contingences specifiques au DAO (connexion a la base de 
donnees, etc.). 
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Les simulacres d'objets avec EasyMock 

Plusieurs frameworks permettent de creer facilement ces simulacres au lieu de les deve- 
lopper manuellement. Pour les besoins de l'ouvrage, nous avons choisi EasyMock, qui 
est l'un des plus simples d'utilisation. 

EasyMock est capable de creer des simulacres a partir d'interfaces. Une extension 
permet d'en fournir a partir de classes, mais nous ne l'abordons pas ici, puisque, dans le 
cas d' applications Spring, nous utilisons essentiellement des interfaces. 

Cette section n'introduit que les fonctionnalites principales d'EasyMock. Nous utilisons 
la version 2, qui fonctionne avec Java 5. Pour plus d' informations, voir le site Web dedie 
au framework, a l'adresse http://www.easymock.org. 

Les simulacres bouchons 

Les simulacres les plus simples sont les bouchons, ou stubs. lis consistent a definir, a 
partir d'une interface ou d'une classe de 1' application, une implementation simulant le 
comportement d'un objet reel. Cette simulation consiste generalement, pour chaque 
methode implementee, a renvoyer des valeurs predefinies. 

Supposons que nous desirions tester de facon unitaire la classe ConfigurationManagerlmpl 
en charge de la configuration des parametres de l'application Tudu Lists. Cette classe 
possede une dependance vis-a-vis de l'interface PropertyDAO. Pour pouvoir l'isoler des 
contingences liees a 1' implementation fournie par Tudu Lists de cette interface, il est 
necessaire de creer un simulacre dont nous controlons tres exactement le comportement. 

Avant de programmer notre simulacre, definissons rapidement son comportement au 
moyen de la methode getProperty, seule utile pour notre test : 

• Si le parametre de getProperty vaut « key », renvoyer un objet Property dont l'attribut 
key vaut « key » et dont l'attribut val ue vaut « value ». 

• Dans tous les autres cas, renvoyer par defaut un objet Property dont les attributs key et 
val ue valent tous les deux « default ». 

Maintenant que nous avons defini les comportements du simulacre, nous pouvons le definir 
au sein d'un cas de test : 

package tudu. service. impl ; 

import static org. easymock. EasyMock. *;<-© 



import junit.f ramework.TestCase; 
import tudu.domain.dao. PropertyDAO; 
import tudu. domain. model .Property; 



public class ConfigurationManagerlmpl ECTest extends TestCase 



private PropertyDAO propertyDAO = null; 

private ConfigurationManagerlmpl configurationManager = nul 
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protected void setUpO throws Exception { 
propertyDAO = createMocktPropertyDAO. class) 
configurationManager = new ConfigurationManagerlmpl ( ) ; 
conf igurationManager. set PropertyDAO (propertyDAO) ;<-© 



public void testGetPropertyt ) { 

Property property = new PropertyO; 
property . setKey( "key" ) ; 
property . setVal ue( "val ue" ) ; 
expect (propertyDAO. get Property ( "key" ) ) 
.andStubReturn(property) ;<-© 

Property defaultProperty = new PropertyO; 
defaul t Property .set Key ( "defaul t") ; 
defaul t Property .setVal ue( "defaul t" ) ; 
expect (propertyDAO. get Property ( (String)anyObject( ) )) 
. andStubRet urn (defaultProperty) ;<-© 

replay(propertyDAO) 

Property test = configurationManager. getProperty( "key" ) ; 
assert Equal s( "val ue" , test .getVal ue( ) ) ; 
test = configurationManager. getPropertyC'anything") ; 
assert Equal s( "defaul t" ,test .getVal ue( ) ) ; 

veri fy (propertyDAO) ; <-© 



Pour simplifier l'ecriture du code necessaire a la definition des simulacres, des imports 
statiques, nouveaute introduite avec Java 5, sont utilises (repere Q). Les imports stati- 
ques permettent de ne plus avoir a specifier la classe (en l'occurrence la classe org. easy- 
mock. EasyMock) lors des appels a ses methodes statiques. 

Nous avons redefini la methode setup, heritee de TestCase, afin de creer le simulacre et de 
l'injecter manuellement dans le manager. La creation du simulacre consiste a creer une 
instance d'objet implementant l'interface PropertyDAO en utilisant la methode createMock 
(repere Qi). Cette methode prend en parametre l'interface que le simulacre doit imple- 
menter, en l'occurrence PropertyDAO. 

Une fois le simulacre cree, nous l'injectons manuellement dans le manager, puisque nous 
sommes dans le cadre de tests unitaires, c'est-a-dire sans conteneur (repere ©). 

Pour que le simulacre fonctionne, il est necessaire de specifier le comportement de 
chacune de ses methodes publiques utilisees dans le cadre du test. C'est ce que nous 
faisons au debut de la methode testGetProperty (reperes Q et ©) en utilisant la methode 
statique expect de la classe EasyMock. 
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Au repere ©, nous specifions le comportement de la methode getProperty de propertyDAO 
lorsque celle-ci a comme parametre « key », c'est-a-dire la valeur que la methode doit 
renvoyer, en l'occurrence l'objet property. Pour cela, nous passons en parametre a expect 
l'appel a getProperty proprement dit. Nous utilisons ensuite la methode andStubReturn de 
l'objet renvoye par expect pour specifier la valeur de retour correspondant au parametre 
« key ». 

Au repere©, nous specifions le comportement par defaut de getProperty, c'est-a-dire 
quel que soit son parametre. Pour indiquer que le parametre attendu peut etre n'importe 
lequel, nous utilisons la methode anyObject d'EasyMock. La valeur de retour est, la 
encore, specifiee avec la methode andStubReturn. 

Pour pouvoir executer le test unitaire proprement dit, il suffit d'appeler la methode repl ay 
en lui passant en parametre le simulacre (repere ©). Nous indiquons ainsi a EasyMock 
que la phase d'enregistrement du comportement du simulacre est terminee et que le test 
commence. Une fois le test termine, un appel a la methode verify (repere ©) permet de 
verifier que le simulacre a ete correctement utilise (toutes les methodes ont-elles bien ete 
appelees, par exemple ?). 

Si nous executons notre test unitaire, nous constatons que tout se deroule sans accroc, 
comme l'illustre la figure 17.5. 



Figure 17.5 

Execution du cas de test 
avec bouchon 



Package Explorer Navigator 



Finished after 0,111 seconds 

<j. ■ | <%> 9i 51 



Runs: 1/1 □ Errors: 0 □ Failures: 0 



3° Failures J= Hierarchy 



tudu.se rvtee.impl.ConfigurationManagerlmplECTe 



testGetProperty 



= Failure Trace 



> 



Notons que si une methode dont le comportement n'est pas defini est appelee, une erreur 
est generee. II est possible d'affecter un comportement par defaut a chaque methode en 
utilisant la methode createNiceMock au lieu de createMock. Son interet est toutefois 
limite, car ce comportement consiste a renvoyer 0, f al se ou nul 1 comme valeur de retour. 
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Enfin, pour simuler une methode sans valeur de retour (void), il est inutile d'utiliser 
expect, un simple appel etant suffisant. 

Les simulacres avec contraintes 

Le framework EasyMock permet d'aller plus loin dans les tests d'une classe en specifiant 
la facon dont les methodes du simulacre doivent etre utilisees. 

Au-dela de la simple definition de methodes bouchons, il est possible de definir des 
contraintes sur la fagon dont elles sont utilisees, a savoir le nombre de fois ou elles sont 
appelees et l'ordre dans lequel elles le sont. 

Definition du nombre d'appels 

EasyMock permet de specifier pour chaque methode bouchon des attentes en terme de 
nombre d'appels. La maniere la plus simple de definir cette contrainte consiste a ne pas 
definir de valeur par defaut, autrement dit a supprimer le code au niveau du repere 0 et a 
remplacer la methode andStubReturn par la methode andReturn. 

EasyMock s' attend alors a ce qu'une methode soit appelee une seule fois pour une 
combinaison de parametres donnee. Si, dans l'exemple precedent, apres ces modifica- 
tions, nous appelons la methode getProperty avec le parametre « key » deux fois dans 
notre test, une erreur d'execution est generee, comme l'illustre la figure 17.6. 



Figure 17.6 

Appel inattendu a la 
methode getProperty 



= Failure Trace j^f 
':. java.lang.AssertionError: 

Unexpected method call getPropertyC'key"): 
getProperty("key"): expected: 1, actual: 1 (+1) 
= at org.easymockJnternal.MocklnvocatbnHandler.invok 
= at org.easymock.internal.Ob]ectMethodsFilter.invoke(C 
= at SPraxy0.getProperty(Unknown Source) 
= at tudu.servfce.impl.ConfiguratbnManagerlmpl.getProp 
= at tudu.servte.impl.ConfigurattonManagerlmplECTest.l 
S at sun.reflect.NativeMethodAccessorImpl.invokeO(Nati\ 
= at sun.reflert.NativeMethodAccessorImpl.invoke(UnkrK 
= at sun.reflect.DetegatingMethodAccessorImpl.invoke(Ui 



L'erreur affichee indique que l'appel a la methode getProperty est inattendu (unexpec- 
ted). Le nombre d' appel de ce type attendu (expected) et effectif (actual) est precise. En 
1' occurrence, le nombre attendu d' appel est 1, et le nombre effectif 2(1 + 1). 

De meme, si la methode getProperty n'est pas appelee avec le parametre « key », une erreur 
est generee puisque EasyMock s'attend a ce qu'elle soit appelee une fois de cette maniere. 

Pour definir le nombre de fois oil une methode doit etre appelee, nous disposons des 
quatre methodes suivantes, a utiliser sur le resultat produit par andReturn : 

• timesO'nt nbre) : specine un nombre d' appels exact. 

• timesO'nt min.int max) : specifie un nombre d'appels borne. 
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• atLeastOnce : specifie que la methode doit etre appelee au moins une fois. 

• anyTimes : le nombre d'appels est quelconque (y compris 0). 

Le code ci-dessous specifie un nombre d'appels egal a 2 : 

expect ( property DAO. get Property ( "key" ) ) 
.andReturn(property) .times(2); 

Si nous executons notre test appelant deux fois getPropertyC'key") avec ce nouveau 
simulacre, nous n'obtenons plus d'erreur. 

Definition de I'ordre d'appel des methodes 

L'ordre d'appel des methodes peut etre important pour tester la facon dont un objet mani- 
pule les autres. Avec EasyMock, nous pouvons definir l'ordre dans lequel les methodes 
d'un simulacre doivent etre appelees. 

Pour tenir compte de l'ordre, il suffit de remplacer la methode createMock du controleur 
par createStrictMock. L'ordre d'appel des methodes est alors defini par la sequence de 
leur appel pour la definition du simulacre. 

Pour tester l'effet de cette modification, modifions le code de notre test. Juste apres le 
repere 0, definissons le comportement de getProperty avec le parametre « another » : 

another Property .set Key ( "another" ) ; 
another Property .setVal ue( "something" ) ; 
expect (property DAO. get Property ( "another" ) ) 
.andReturn(anotherProperty) ; 

Introduisons ensuite le test suivant juste apres le premier test de la methode getProperty : 

test = configurationManager.getProperty("another"); 
assert Equal s( "something" . test .getVal ue( ) ) ; 

Si nous effectuons cette modification sur le code precedent sans autre modification, nous 
obtenons le resultat illustre a la figure 17.7. 



Figure 17.7 

Resultat du non-respect 
de l'ordre d'appel 



= Falure Trace | > S° 

' ! junit.framework.ComparisonFailure: expected: <something > but was: <default> 
= at tudu.servlce.impl.ConfigurafDnManagerImplECTest.testGetProperty(Configu 
= at sun.reflect.NativeMethodAccessorImpl.invokeO(Native Method) 
= at sun.reflect.NativeMethodAccessorlmpl.invoke(Unknown Source) 
= at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 



L'erreur indique que la valeur de retour attendue etait celle du comportement par defaut, 
puisque le comportement avec le parametre « another » a ete defini apres le comportement 
avec le parametre « key », qui n'a pas encore ete appele. 
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Les simulacres d'objets de Spring 

Spring n'etant pas un framework dedie aux tests unitaires, il ne fournit pas de services 
similaires a ceux d'EasyMock. Cependant, afin de faciliter l'ecriture de tests unitaires, 
Spring fournit un ensemble de simulacres prets a l'emploi. Ces simulacres simulent des 
composants standards de 1' API J2EE souvent utilises dans les applications. 

L'ensemble de ces simulacres est defini dans des sous-packages de org.springfra- 
mework.mock. 

Les simulacres JNDI 

Dans le package org. springframework. mock, jndi, sont definis les simulacres necessaires a 
la simulation d'un annuaire JNDI. Ces simulacres sont notamment utiles lorsqu'un 
composant doit obtenir via un annuaire la reference a un autre objet, typiquement une 
source de donnees. 

Le code suivant montre comme ces simulacres sont utilises pour definir un annuaire refe- 
rencant une source de donnees : 

import org.springf ramework. jdbc.datasource.DriverManagerDataSource; 
import org.springf ramework. mock. jndi .SimpleNamingContextBuilder; 
(...) 

SimpleNamingContextBuilder builder = 
new Simpl eNamingContextBuilder( ) ; 

DataSource ds = new DriverManagerDataSourceCorg.hsqldb.jdbcDriver" 
," jdbc:hsqldb:mem:tudu ","sa",""); 

bui 1 der .bind( "java:comp/env/jdbc/tudu" , ds ) ; 

try { 

builder. activate( ) ; 

} 

catchtNamingException e) { 

throw new RuntimeExceptionC'Probleme dans 1 'activation JNDI"); 

} 

Dans cet exemple, nous associons une source de donnees (ds) a la cle java:comp/env/ 
jdbc/tudu. Ce code est utilise dans la methode launch de la classe HsqldbLauncher du 
package tudu.domain.dao.hibernate3. Cette classe a la charge de creer en memoire la base 
de donnees qui est utilisee pour nos tests. 

Les simulacres Web 

Dans le package org.springf ramework. mock. web, sont definis les simulacres necessaires 
pour tester des composants Web. Nous y trouvons des simulacres pour les principales 
interfaces de 1' API servlet, notamment les suivants : 



• HttpServletRequest 
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• HttpServletResponse 

• HttpSession 

Dans Tudu Lists, nous disposons d'une servlet pour effectuer la sauvegarde du contenu 
d'une liste de todos. Le code suivant, extrait de la classe BackupServletTest du package 
tudu. web. servlet, montre comment les simulacres Web MockHttpServletRequest, 
MockHttpServl etResponse et MockHttpSession sont utilises pour tester cette servlet dans un 
cas de test JUnit classique : 

public void testDoGetO throws Exception { 
Document doc = new DocumentO; 
Element todoListElement = new El ementt "todol ist" ) ; 
todol_istElement.addContent( 

new Element("title").addContent("Backup List")); 
doc. addContentttodoListEl ement) ; 

MockHttpServletRequest request = new MockHttpServl etRequestC ) ; 
MockHttpSession session = new MockHttpSessionO; 
session. setAttributeC'todoListDocument", doc) ; 
request. setSessi on (session) ; 

MockHttpServl etResponse response = 
new MockHttpServl etResponseC ) ; 

BackupServlet backupServlet = new BackupServletO; 
backupServlet. doGet(request, response) ; 

String xmlContent = response. getContentAsString( ) ; 

assertTruetxml Content. indexOf ("<title>Backup List</title>")>0) ; 

} 

Le code en gras, qui concentre l'utilisation des simulacres, montre que l'emploi de ces 
derniers est tres aise. Leur creation ne necessite aucun parametrage particulier, et toutes 
les methodes pour definir leur contenu puis le recuperer sont disponibles. 



Autres considerations sur les simulacres 

Pour terminer cette section consacree aux simulacres d'objets, il nous semble important 
d'insister sur deux points fondamentaux pour bien utiliser les simulacres : 

• Un cas de test portant sur un objet utilisant des simulacres ne doit pas tester ces 
derniers. L'objectif des simulacres est non pas d'etre testes, mais d'isoler un objet des 
contingences exterieures arm de faciliter sa verification. 

• Un simulacre doit etre concu de maniere a produire des donnees susceptibles de 
generer des erreurs dans l'objet a tester. Le passage des tests ne demontre pas qu'un 
objet fonctionne correctement, mais demontre seulement qu'il a su passer les tests. 
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EasyMock repond a des besoins moyennement complexes en terme de simulacres. Pour 
des besoins plus complexes, il est conseille de developper specifiquement les simulacres 
sans l'aide d'un framework. 

En resume 

Comme pour les tests avec JUnit, les principes architecturaux de Spring facilitent la crea- 
tion de simulacres. D'une part, la separation des interfaces et de leurs implementations 
permet d'utiliser nativement EasyMock sans passer par une extension permettant de 
realiser des simulacres a partir de classes. D'autre part, l'injection des dependances dans 
le composant pouvant etre faite manuellement, done sans le conteneur leger, il est aise 
d'initialiser les collaborateurs du composant a tester, non pas avec des implementations, 
mais avec des simulacres permettant de l'isoler des contingences exterieures. 

Les simulacres prets a l'emploi fournis par Spring sont tres utiles en ce qu'ils simulent 
des classes standards de l'API Java, tres utilisees dans les applications J2EE. 

Les tests d' integration 

JUnit et EasyMock suffisent dans la plupart des cas a realiser des tests unitaires. Les tests 
unitaires sont necessaires mais pas suffisants pour tester le bon fonctionnement d'une 
application. Les tests d'integration viennent en complement pour garantir que l'integra- 
tion entre les composants de l'application s'effectue correctement. 

Dans cette section, nous mettrons en ceuvre aussi bien le conteneur leger que la base de 
donnees, voire un simulacre de conteneur de servlets (pour tester les actions Struts, par 
exemple). Pour cela, nous utilisons, d'une part, les extensions de Spring a la classe Test- 
Case de JUnit, afin de faire fonctionner le conteneur leger dans le cadre des tests d'inte- 
gration, et, d'autre part, le framework StrutsTestCase pour tester les actions Struts. 

Les extensions de Spring pour JUnit 

Comme nous l'avons deja indique, JUnit peut etre utilise aussi bien pour faire des tests 
unitaires que pour faire des tests d'integration. C'est done tout a fait naturellement que 
Spring fournit des extensions a JUnit afin de pouvoir tester 1' integration des composants 
de l'application. Ces extensions ont pour vocation d'instancier le conteneur leger afin de 
beneficier de l'injection de dependances et de la POA. 

Ces extensions se presentent sous la forme de classes derivees de junit. framework. Test- 
Case, contenue dans le package org. springf ramework. test. Spring definit quatre classes 
abstraites permettant d'utiliser le conteneur leger et la POA. 

Ces classes apportent une reponse graduee aux besoins des tests d'integration : 

• AbstractSpringContextTests. Classe de base des trois autres, elle definit leur fonction- 
nement commun et ne doit normalement pas etre utilisee pour implementer un cas de 
test. 
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• AbstractDependencylnjectionSpringContextTests. Permet d'utiliser le conteneur leger et 
1' injection de dependances. Pour cela, les fichiers de configuration sont specifies en 
surchargeant la methode getConfigLocations (voir I'exemple donne plus loin). 

• AbstractTransactionalSpringContextTests. Permet d'utiliser le conteneur leger dans un 
cadre transactionnel. Cette classe offre les memes services que precedente, mais a la 
fin des tests, un rollback global est effectue pour annuler les modifications persistantes 
induites par le test. 

• AbstractTransactional DataSourceSpringContextTests. Offre les memes services que la 
precedente et donne la possibility de vider completement une ou plusieurs tables de la 
base lors des tests. 

Ces classes utilisent uniquement 1' injection automatique des dependances en se fondant 
sur les types. II faut done prendre en compte ce mode de fonctionnement dans la realisation 
des tests. 

Pour demontrer l'utilite de ces extensions, nous allons creer un test d'integration pour un 
des DAO de Tudu Lists, en l'occurrence UserDAOHibernate. II s'agit d'un test d'integration, 
car la base de donnees est mise en ceuvre. 

A cette fin, nous allons creer une sous-classe de AbstractTransactional SpringContext- 
Tests, car cette classe est en mesure de rendre la base de donnees dans son etat initial 
apres les tests. Le test s'execute en effet dans un contexte transactionnel sur lequel la 
classe effectue un rollback a la fin. 

Le code suivant montre notre cas de test UserDAOHibernateTest, qui utilise les services de 
AbstractTransactional SpringContextTests : 

package tudu. domain. dao. hi bernate3; 
(...) 

public class UserDAOHibernateTest extends 

AbstractTransactional SpringContextTests { 



static {<-© 

Hsqldb Launcher . 1 auncht ) ; 

} 

private User newUser = null; 
private UserDAO dao = null; 

public void setDao(UserDAO dao) {<-© 
this. dao = dao ; 

} 



protected String[] getConfigLocationst ) {<-© 
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String webappDir = System. getProperty( "TUDU_WEBAPP_DIR" ) ; 
i f (webappDi r == null ) { 
webappDir = "WebContent" ; 

} 

return new String[] { 

"file:" + webappDir + "/WEB-INF/applicationContext.xml", 
"file:" + webappDir 

+ "/WEB-INF/appl icationContext-hibernate.xml " }; 

} 

protected void onSetUpBeforeTransaction( ) throws Exception {<-© 
super.onSetUpBeforeTransaction( ) ; 
newUser = new User( ) ; 
newUser.setEmail ("email@test.com") ; 
newUser.setEnabled(true) ; 
newUser . setLastName( "1 astName" ) ; 
newUser.setLoginC'testUser") ; 
newUser .set Password ( "password" ) ; 
HashSet<Role> roles = new HashSet<Rol e>( ) ; 
Role role = new RoleO; 

role.setRole(RolesEnum.ROLE_USER.toString()); 
roles. add(role) ; 
newUser. set Roles (roles) ; 



protected void onSetUpInTransaction( ) throws Exception {<-© 
super. onSetUpInTransaction( ) ; 

} 

public void testSaveUser( ) {<-© 
dao. s a veUsert newUser) ; 
User user = dao.getUser( "testUser" ) ; 
assert Equal s( newUser. getl_astName( ) .user .get LastNamet ) ) ; 



public void testUpdateUser( ) {<-© 
dao.saveUser(newUser) ; 
newUser .set Las tName( "newLastName" ) ; 
dao. updateUser( newUser) ; 
User updatedUser = dao.getUserC'testUser"); 
assert Equal s( newUser .get LastName( ) , updatedUser .get Last Name ( ) ) ; 




Ce cas de test comprend plusieurs elements importants necessaires a la realisation des 
tests d'integration de notre DAO. Tout d'abord, la classe comporte un bloc statique 
(repere Q>. qui initialise la source de donnees en utilisant les services de la classe Hsqld- 
bLauncher. 
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L'attribut dao contient l'instance de la classe a tester. Cet attribut est initialise par le 
conteneur leger par le biais de sa fonctionnalite d'injection automatique via le modificateur 
setDao (repere 0). 

En surchargeant la methode getConfigLocations (repere 0), nous definissons les fichiers 
de configuration du conteneur leger dans le cadre du cas de test. Ces fichiers de configu- 
ration doivent etre accessibles par defaut depuis le repertoire WebContent\WEB-INF. II 
est possible de remplacer WebContent par un autre repertoire specifie dans la propriete 
systeme TUDU_WEBAPP_DIR. Nous utilisons ici les memes fichiers de configuration que 
l'application, car ils n'ont pas besoin d'etre adaptes specifiquement pour les tests. 

Contrairement a la classe TestCase definie par JUnit, AbstractTransactionalSpringContext- 
Tests fournit non pas une, mais deux methodes d' initialisation des tests. La premiere, 
onSetUpBeforeTransaction (repere 0), est destinee aux initialisations pouvant s'effectuer 
en dehors du contexte transactionnel. II s'agit done de traitements n'ayant pas d'impact 
sur la persistance des donnees. Dans notre exemple, il s'agit des variables necessaires 
aux tests. La seconde, onSetUpInTransaction (repere 0), est destinee aux initialisations 
devant s'effectuer dans le contexte transactionnel. Dans les deux cas, il est necessaire 
d'appeler la methode de la classe mere via super, comme avec la methode setlip de la 
classe TestCase. 

Grace a l'ensemble de ces initialisations, nous pouvons tester la classe UserDAO en l'utili- 
sant comme a l'interieur des services de Tudu Lists (reperes 0 et Q). Comme nous 
pouvons le constater, les tests modifient le contenu de la base de donnees. Fort heureuse- 
ment, la classe AbstractTransactionalSpringContextTests effectue un rollback a la fin des 
tests, ce qui a pour effet de rendre a la base son etat initial. 

Utilisation de StrutsTestCase avec Spring 

StrutsTestCase est une extension de JUnit pour tester le code utilisant le framework Struts. 
StrutsTestCase supports les specifications servlet 2.2, 2.3 et 2.4, ainsi que la version 1.2 de 
Struts. Ce framework est disponible a l'adresse http://strutstestcase.sourceforge.net. 

Nous ne presentons ici de ce framework que l'essentiel pour tester Tudu Lists. Le lecteur 
desirant en savoir plus peut se referer a la documentation fournie sur le site Web de 
StrutsTestCase. 

Cette extension se presente sous la forme de deux classes derivant de TestCase. La 
premiere, MockStrutsTestCase, offre un simulacre de conteneur de servlets a meme 
d'executer le code fonde sur Struts. Ce simulacre a l'avantage d'etre beaucoup plus leger 
qu'un veritable conteneur de servlets, comme Tomcat. La contrepartie est un support 
partiel de 1' API servlet. La seconde, CactusStrutsTestCase, utilise le framework Cactus de 
la communaute Apache Jakarta pour executer le code de test directement dans un verita- 
ble conteneur comme Tomcat. Avec cette deuxieme classe, toutes les fonctionnalites de 
l'API servlet sont supportees. 

Nous presentons ici la version avec simulacre, sachant que la version avec Cactus ne 
presente pas de difference significative pour la programmation des tests unitaires. 
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Pour utiliser StrutsTestCase avec Spring, le repertoire WEB-INF doit etre accessible 
depuis le classpath. En effet, StrutsTestCase interprete directement les fichiers de confi- 
guration XML, principalement struts-config.xml. II est aussi possible d'indiquer a 
StrutsTestCase 1' emplacement exact des differents fichiers dont il a besoin. C'est ce que 
nous realisons dans la classe TuduBaseMockStrutsTestCase du package tudu.web : 

public class TuduBaseMockStrutsTestCase 
extends MockStrutsTestCase { 

protected void setUpO throws Exception ( 
super. setUp( ) ; 
(...) 

String webappDir = System. getProperty("TUDU_WEBAPP_DIR") ; 
if (webappDir == null ) { 

webappDir = "WebContent" ; 

} 

File webXml = new FiletwebappDir + "/WEB-INF/web.xml " ) ; 
if (IwebXml .existsO) { 

fail ("web. xml not found."); 

} 

File context = new File(webappDir); 
if ( ! context. exists( ) ) { 

fai 1 ( "context directory not found."); 

} 

File strutsXml = new FiletwebappDir + "/WEB-INF/struts-config.xml ") ; 
if OstrutsXml .existsO) { 

fail ("struts-config.xml not found."); 

} 

this.setServletConfigFile(webXml .getAbsol utePath( )) ; 
this.setConfigFiletstrutsXml .getAbsolutePath( )) ; 
this .setContextDi rectory (con text) ; 

} 

} 

Cette classe est la mere de tous nos cas de test fondes sur StrutsTestCase. 

Notons qu'une limitation de StrutsTestCase empeche d'utiliser le symbole * dans la definition 
des fichiers de configuration Spring du plug-in org. springframework. web. struts. ContextLoa- 
derPlugln. II est done necessaire de lister nominativement chaque fichier de configuration a 
charger par Spring. 

Pour Tudu Lists, le fichier struts-config.xml doit contenir la definition suivante : 
<plug-in cl assName=" org. springframework. web. struts. Context Loader PI ugln"> 

<set-property property="contextConfig Location" val ue="/WEB-INF/appl ication- 
*»Context-dwr.xml ,/WEB-INF/appl icationCon text- hibernate. xml , /WEB- INF/ 
^►appl i cat ionContext- security. xml , /WEB- 1 NF/appl icationCon text. xml , /WEB- INF/ 
*»action-servlet.xml "/> 



</pl ug-in> 
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Pour terminer, notons que le framework de securite Acegi Security utilise pour Tudu 
Lists repose sur un filtre servlet. Or, comme nous l'avons deja indique, le simulacre de 
StrutsTestCase ne supporte pas les filtres. Cela a pour consequences de ne pas charger 
le contexte de securite et d'empecher l'execution de 1' application. II est done necessaire de 
charger manuellement un contexte de securite pour permettre les tests. 

Le cas de test suivant montre comment tester Taction Struts tudu. web ShowTodosAction en 
derivant la classe MockStrutsTestCase : 

package tudu. web; 



import org. acegi security. GrantedAuthority; 

import org. acegi security .context. SecurityContextHolder; 

import org. acegisecurity. context. SecurityContextlmpl ; 

import org. acegi security .providers. Test ingAuthenti cat ionToken; 

import org. acegi security .userdetai Is. User; 



import servlet unit. st ruts. MockStrutsTestCase; 



public class ShowTodosActionTest extends TuduBaseMockStrutsTestCase { 



protected void setUpO throws Exception {<-© 
super. setUpt ) ; 

SecurityContextlmpl ctx = new SecurityContextlmpl () ; 
GrantedAuthority authority = new GrantedAuthority( ) { 
public String getAuthority( ) { 
return "ROLE_ADMIN" ; 

} 

}; 

User user = new UserC'admin", "admin", true, true, true 

.false, new GrantedAuthority[] { authority }); 

TestingAuthenticationToken token = 

new TestingAuthenticationToken(user, null 

, new GrantedAuthority[] { authority }); 

ctx.setAuthenti cat ion (to ken) ; 

SecurityContextHolder .setContext( ctx) ; 



public void testDi spl ay( ) {<-© 

setRequestPathInfo( "/secure/showTodos") ; 
addRequestParametert "1 i stld" 

, "f f808081085el8f c01085el9a3820002" ) ; 
actionPerformt ) ; 
verifyForwardC'show") ; 

} 

} 
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L' initialisation du contexte de securite comporte trois volets (repere Q) : 

• Definition de l'utilisateur (au sens d'Acegi Security) sous lequel le code va etre 
execute. Dans notre cas, il s'agit de l'utilisateur « admin », ayant pour mot de passe 
« admin » et role « ROLE_ADMIN ». Cette definition est stockee dans l'objet user. 

• Association de l'utilisateur a un jeton d'authentification, ici token. Ce jeton est de type 
TestingAuthenticationToken afin de signifier a Acegi Security que 1' authentification se 
fait dans le cadre d'un test. 

• Association du jeton au contexte de securite ctx via la methode setAuthenti cation puis 
definition de ctx comme etant le contexte de securite de 1' application via la methode 
setContext de la classe Securi tyContextHol der. 

Apres ces initialisations necessaires pour faire fonctionner 1' application, les tests peuvent 
etre effectues. Ces tests ne necessitent plus que l'utilisation des fonctionnalites offertes 
par StrutsTestCase. 

Les tests avec StrutsTestCase s'effectuent en quatre temps (repere Q) : 

1. Definition de Taction Struts a tester. Cette definition s'effectue en donnant a la 
methode setRequestPathlnfo la reference de Taction dans le fichier struts-config.xml, 
et non le nom de la classe action a tester, soit ici la classe ShowTodosAction. Dans notre 
exemple il s'agit de Taction /secure/showTodos. 

2. Definition des parametres attendus par Taction. Cette operation s'effectue via la 
methode addRequestParameter. Dans notre exemple, nous definissons la valeur du 
parametre 1 i stld, qui est Tidentifiant de la liste de todos utilisee pour le test. 

3. Execution de Taction via la methode actionPerform. StrutsTestCase simule alors le 
conteneur et execute en son sein Taction specifiee precedemment. 

4. Verification du resultat de T execution en analysant la redirection renvoyee par 
Taction grace a la methode verifyForward. Dans notre exemple, il s'agit de verifier 
que Taction redirige vers la reference show definie dans le fichier struts-config.xml. 

Outre la methode verifyForward, il est possible de verifier Tabsence d'erreur (du type 
ActionError) dans T execution de Taction Struts grace a la methode verifyNoActionErrors. 

StrutsTestCase offre en outre la possibility de recuperer la session grace a la methode 
getSession. Nous pouvons ainsi acceder aux variables stockees en session pour les tester, 
comme le montre le code ci-dessous : 

assertNul 1 ( (String) getSessiont ) .getAttributet "todoLi st Document" ) ) ; 



En resume 

Les tests d'integration utilisant JUnit sont facilites pour les applications qui utilisent 
Spring. Le framework fournit des specialisations de la classe TestCase de JUnit, qui 
permettent d'utiliser le conteneur leger en dehors de tout serveur d' applications. 



Les outils connexes 

Partie V 



Spring est en mesure de fonctionner avec le framework StrutsTestCase utilise pour tester 
les developpements fondes sur Struts. Le simulacre de conteneur de servlets utilise par ce 
framework est capable d'instancier le conteneur leger de Spring, moyennant une legere 
modification du fichier de configuration de Struts. 



Conclusion 

Ce chapitre a montre comment tester une application Spring avec JUnit. Du point de vue 
des tests unitaires, le code fonde sur Spring ne necessite pas d'extension particuliere a 
JUnit, hormis l'utilisation le cas echeant d'un framework specifique, comme EasyMock, 
pour simuler les objets dont depend le composant a tester. 

Spring fournit par ailleurs des simulacres prets a l'emploi pour certains composants tech- 
niques de l'API J2EE. Pour les tests unitaires, seul le code applicatif est utilise, sans 
l'aide du conteneur leger de Spring. L' injection des dependances est effectuee manuellement 
dans les tests. 

Pour les tests d' integration, JUnit necessite plusieurs extensions, car, dans ce cas, le 
conteneur leger doit etre utilise. A cette fin, Spring fournit des classes derivant de Test- 
Case de JUnit pour instancier le conteneur leger specifiquement pour les tests. Spring peut 
aussi fonctionner avec StrutsTestCase pour tester l'integration des composants utilisant les 
deux frameworks. 

En conclusion, nous pouvons constater que 1' architecture applicative qui decoule de 
l'utilisation de Spring s'avere facilement testable, ce qui est un avantage non negligeable 
par rapport a d'autres choix architecturaux. Le code applicatif n'est pas dependant de Spring, 
ce qui permet de le tester en dehors du conteneur leger. De plus, la separation des inter- 
faces et des implementations facilite la creation de simulacres, ce mode de fonctionnement 
etant supporte nativement par les frameworks de type EasyMock. 

Spring fournit un certain nombre de simulacres tres utiles pour les composants depen- 
dants de l'API servlet ainsi que des cas de tests JUnit permettant de masquer completement 
l'instanciation du framework. 



Annexe 



Cette annexe fournit les procedures de telechargement et d' installation des outils neces- 
saires a la realisation de 1' application exemple Tudu Lists. 

Ces outils etant tous issus de la communaute Open Source, ils peuvent etre utilises 
gratuitement dans vos projets. 

Installation cT Eclipse WTP 

Eclipse WTP (Web Tools Platform) peut etre telecharge gratuitement depuis la page 
Downloads du site Web http://www.eclipse.org/webtools. Cette page propose deux types 
d' archives compressees : All in One et Runtime. Nous conseillons d'utiliser All in One, 
qui contient tous les plug-in Eclipse necessaires a WTP. 

L' archive All in One peut etre decompressed dans n'importe quel repertoire. La decom- 
pression cree une arborescence, dont le repertoire racine est nomme eclipse. 

Une fois la decompression terminee, il suffit de lancer 1' executable (eclipse.exe pour 
Windows) present a la racine du repertoire eclipse pour demarrer l'environnement de 
developpement. 

Telechargement de Tomcat 

Le programme d'installation du moteur de servlets/JSP Tomcat est disponible a la sous- 
rubrique Binaries de la rubrique Download du site Web de Tomcat (http://jakarta.apache.org/ 
tomcat). 

Tomcat necessite l'installation prealable d'un JDK, dont la version est specifiee dans la 
documentation fournie sur le site Web. Pour Tomcat 5, il s'agit du JDK 1.5. 

L application Tudu Lists utilise les parametres par defaut proposes par 1' assistant 
d'installation : 

1. Apres avoir installe Tomcat, lancez-le, et verifiez que la page affichee par l'URL http:/ 
/localhost:8080 correspond a la page d'accueil de Tomcat. 
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Au besoin, remplacez 8080 par le port que vous avez specifie au moment de 1' instal- 
lation. 

II ne faut pas oublier d'arreter Tomcat apres ce test pour pouvoir utiliser WTP, qui lance 
sa propre instance de Tomcat. 

Installation de MC4J 

Le programme d' installation de MC4J est disponible a l'URL http://sourceforge.net/project/ 
showfiles.php?group_id=60228. II est imperatif d' avoir installe au prealable un JRE version 1.4 
ou 1.5 sur la machine oil MC4J est installe : 

1. Une fois l'installation lancee, un ecran d'accueil afhche un bref descriptif du produit. 
Cliquez sur Next. 

2. L' ecran suivant permet de selectionner le JRE a utiliser par MC4J. Une fois la selec- 
tion effectuee, cliquez sur Next. 

3. Specifiez le repertoire d'installation de MC4J, puis cliquez sur Next. 

4. Indiquez au programme comment generer les icones de lancement de MC4J. Cliquez 
sur Next pour l'installation des fichiers. 

5. Une fois l'installation terminee, cliquez sur Done. 
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